Re: [dev] Learn C
On Tue, Apr 02, 2019 at 05:44:35AM +0200, Markus Wichmann wrote: > I was being quite serious. Not everything posted on April 1st is a joke. > I eventually got fed up with harmful.cat-v.org, because all it listed > was derision, but no actual justification. Just like you. In a suckless context, those who add complexity to syntax which does increase the near absolute metric of "technical cost" (not to mention the "human factor"), _they_ have to justify themselves. I am tired too... to remind all the time those basics to people I should not remind anything, just like you. -- Sylvain
Re: [dev] Learn C
> What a strange reply. Clearly *some* abstractions are good, otherwise > we'd all be writing assembly. *How many* abstractions exactly is a > matter of contention and personal taste. But as soon as someone > slightly disagrees with you on a fairly minor point you resort to > insults and "bruh huh, not true suckless". > > Frankly, these sort of comment are unbecoming of a serious programmer, > suckless or not. Most "abstractions" hard-wired in computer languages have a technical cost and a "I want to write the most complex programs with a maximum abstractions constructs to feel smart" cost (the human factor). It seems that, when some peers are told their lovely "abstractions" are kind of "not worth their cost", they start insulting the disagree-ing peers with the "we'd would be writing assembly". Writing assembly, in the right context, is very good thing. I did write assembly (68000 and x86, the ez ones), some programs of significant and different sizes. Some people pushed it even harder with a small OS (menuet OS). I am pretty sure many of the originators of such an insult have no idea of what significant features a simple computer language like C brings on top of raw assembly and why it is doing too much already. -- Sylvain
Re: [dev] Learn C
Not that this sort of thread can really go anywehere else, sadly, but please refrain to getting aggressive with each others. We all saw there was a lot of *opinions*, albeit written as dogmas, let the reader be smart and see which are to be adopted and which be rejected, and which to be ignored (not argumented).
Re: [dev] Learn C
On Mon, Apr 01, 2019 at 07:34:20PM +0200, Markus Wichmann wrote: > you aren't exactly a beacon of sunshine either. You like to make > normative claims all over the place, but when asked to defend them, you > only have names to call people. Maybe C++ is genuinely as horrible as > you say. I have seen evidence of that. But most of it boils down to "if > you use it wrong, it turns into spagghetti code in a pretty dress". > Well, C's the same way, sans pretty dress. Don't worry, you aren't such a beacon neither... like if anybody could be here. Simple C or "reduced/fixed syntax" C is the _less worse_ technical _compromise_ above machine code, for now. Let me recall you something: there is no thing as good code, only code that "suckless"... > That first sentence of David's answer is merely the logical conclusion > of thinking your restrictions to the end. In suckless context, this is near an insult. I don't need to loose too much of my time with such human being, and I won't. Let them code amazing-ly abstracted c++52 or python12 or viper7 code... but if it could be on msdn where it's more appropriate... -- Sylvain
Re: [dev] Learn C
On Mon, 1 Apr 2019 16:56:21 + sylvain.bertr...@gmail.com wrote: > Dear David, > > You are of the type of human being I, genuinely, sort of dislike. Namely a > syntax > kludge and excessive abstraction lover. > > Your first sentence is already an insult to "suckless" people: "won't you > write > in assembly next time?" What a strange reply. Clearly *some* abstractions are good, otherwise we'd all be writing assembly. *How many* abstractions exactly is a matter of contention and personal taste. But as soon as someone slightly disagrees with you on a fairly minor point you resort to insults and "bruh huh, not true suckless". Frankly, these sort of comment are unbecoming of a serious programmer, suckless or not. Martin pgp2AErlw1cOi.pgp Description: OpenPGP digital signature
Re: [dev] Learn C
God! I barely did notice we were the first of April... and I was surprised to see ideas so much remote from suckless stated here. Got me guys. I fell for it. doh! -- Sylvain
Re: [dev] Learn C
I know this is bait but I'll bite: People who think this shit in real life are insufferable faggots who have 0 concept of how much abstraction there already is between them programming in "real" languages bare metal. The amount of abstraction that's achieved by going from logic gates to C is fucking astronomical, and you could probably never achieve writing a C compiler from bare metal in your entire life if it weren't for the work of hundreds of years of mathematicians working all this shit out for you. Comparatively, the jump from C to Python is minuscule in the grand scheme of things. Sure it might abstract away a few data structures and make things nicer to use, but it's nothing compared to carefully organizing bits of sand together in such a way that they perform actual computation. Computer science and abstraction are tied together at the hip. Losers who can't understand that the continuous abstraction of mathematics is the very essence of computing are the most obnoxious fucking faggots in the world. The losers who can't understand that it's actually harder to think abstractly are the funniest of them all. Sure you can do the equivalent of hand-holding a modern abacus. You're not accomplishing anything by reinventing the wheel for the thousandth time, you're just doing it because someone needs some retarded shit to be fast, but you're not furthering the field of computer-science. You're not developing new fucking algorithms in C, you're implementing something that someone (far smarter than you) has already thought of in a slightly different flavor just so you can get a paycheck. On Mon, 1 Apr 2019 16:56:21 + sylvain.bertr...@gmail.com wrote: > Dear David, > > You are of the type of human being I, genuinely, sort of dislike. Namely a > syntax > kludge and excessive abstraction lover. > > Your first sentence is already an insult to "suckless" people: "won't you > write > in assembly next time?" > > -- > Sylvain > -- inasprecali
Re: [dev] Learn C
Le 24/03/2019 à 14:33, sylvain.bertr...@gmail.com a écrit :
* do not use enum (hard rule)
I'd be glad to get any reason why not. C is already minimalistic, won't
you write in assembly next time?
Moreover, enums are often well supported in debuggers and show the
actual enum constant rather than its value. Also, compilers are smart
enough to be sure you compare good things:
$ gcc test.c -Wall -Wextra
test.c: In function ‘main’:
test.c:8:8: warning: comparison between ‘enum gender’ and ‘enum color’
[-Wenum-compare]
if (g == red)
^
$ cat test.c
enum gender { male, female };
enum color { red, green, blue };
int main()
{
enum gender g = male;
if (g == red)
return 1;
}
* declare your variables at the beginning of a block (c99 allows declarations a
bit everywhere, bad). personnally I try to keep my variables declared first,
then
the variables with assignment, because it's actually code (presume C
initializers are code).
Welcome to prehistory. Declaring when you use (with a assignment) makes
uninitialized variables less often happening.
* I personnaly add a macro #define loop for(;;) and use only 1 loop
statement (hard rule)
Strange, hiding explicit code for a benefit of 4 keystrokes.
* use sized types: u8 u16 i64 float32 etc... you can use the C
preprocessor to fix that, but in some case, as a good tradeof (for instance
in
"object oriented C code"), add a suffix to your type (u8_t, struct
my_class_t), then
for instance you can nest structs, struct base_type_t base_type.
This is completely nonsense. Do you know that using the appropriate
types is just the best thing to do? For example, it's sometimes even
better to pass an int rather than a bool as argument/return value
because the processor has to perform more steps since it will promotes
the bool to int. In most of the case int is just the way to go. However,
having those fixed size types in PODs for serialization, hardware access
and memory management is clean (but with care of alignment/padding).
Regards,
--
David
Re: [dev] Learn C
On Wed, Mar 27, 2019 at 01:19:23PM -0700, Evan Gates wrote: > On Wed, Mar 27, 2019 at 12:40 PM wrote: > > > > On Wed, Mar 27, 2019 at 07:43:04AM -0700, Evan Gates wrote: > > Style and the amount of actually used syntax is different. > > I'd disagree. Once you choose a language, any choices about how you > write that language are style. I strongly disagree: style with a reduced syntax (for instance without enum, typedef, with only one loop statement, declaring variables at the start of a block) is not the same than style with the full syntax kludge and declaring variable anywhere. -- Sylvain
Re: [dev] Learn C
On Wed, Mar 27, 2019 at 12:40 PM wrote: > > On Wed, Mar 27, 2019 at 07:43:04AM -0700, Evan Gates wrote: > Style and the amount of actually used syntax is different. I'd disagree. Once you choose a language, any choices about how you write that language are style. > > > add a suffix to your type (u8_t, struct my_class_t) > > > > Don't do this if you're using anything POSIX. The _t namespace is > > reserved for POSIX types.[1] > > If I recall properly, I was nesting structs with type names intersecting the C > keywords (float...), any short suffix will do actually or none if not > conflicting with anything. What do you mean by nesting structs?
Re: [dev] Learn C
On Wed, Mar 27, 2019 at 07:43:04AM -0700, Evan Gates wrote: > On Tue, Mar 26, 2019 at 11:21 AM wrote: > > C has already a syntax way too rich and flexible. Most of the > > linux coding guidelines is nice. > > There is also a style page[0] at suckless. But again style is subjective > and the most important thing is consistency within a project. Style and the amount of actually used syntax is different. Style is how you use a set of the syntax. Styles using different sets of the syntax are not to be compared. Here it's not style: it's mostly a reduction of the syntax. Then you could define different styles using the same set of the syntax. But I have to agree, syntax reduction is often, if not always, put in the "style" bag, which I think is wrong. > > add a suffix to your type (u8_t, struct my_class_t) > > Don't do this if you're using anything POSIX. The _t namespace is > reserved for POSIX types.[1] If I recall properly, I was nesting structs with type names intersecting the C keywords (float...), any short suffix will do actually or none if not conflicting with anything. > [1] > http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02_02 On this web page, when I tried to get the definition of the [CX] code related to the _t suffix I got a nice page complaining javascript is nowhere to be found, I had to use google to find the right page... bad omens. -- Sylvain
Re: [dev] Learn C
On Tue, Mar 26, 2019 at 11:21 AM wrote: > C has already a syntax way too rich and flexible. Most of the > linux coding guidelines is nice. There is also a style page[0] at suckless. But again style is subjective and the most important thing is consistency within a project. > add a suffix to your type (u8_t, struct my_class_t) Don't do this if you're using anything POSIX. The _t namespace is reserved for POSIX types.[1] [0] https://suckless.org/coding_style/ [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02_02
Re: [dev] Learn C
On Tue, Mar 26, 2019 at 08:56:07PM +0100, Kurt Van Dijck wrote: > I agree with most of your arguments > > > * use sized types: u8 u16 i64 float32 etc... you can use the C > > preprocessor to fix that, but in some case, as a good tradeof (for > > instance in > > "object oriented C code"), add a suffix to your type (u8_t, struct > > my_class_t), then > > for instance you can nest structs, struct base_type_t base_type. > > Why not use uint8_t etc. from stdint.h? Shorter
Re: [dev] Learn C
I agree with most of your arguments > * use sized types: u8 u16 i64 float32 etc... you can use the C > preprocessor to fix that, but in some case, as a good tradeof (for instance > in > "object oriented C code"), add a suffix to your type (u8_t, struct > my_class_t), then > for instance you can nest structs, struct base_type_t base_type. Why not use uint8_t etc. from stdint.h? Kurt
Re: [dev] Learn C
On Tue, Mar 26, 2019 at 08:37:18PM +0100, Quentin Rameau wrote: > > * do not use enum (hard rule) > > * do not use typedef (hard rule) > > * use sized types: u8 u16 i64 float32 etc... you can use the C > > preprocessor to fix that, but in some case, as a good tradeof (for > > instance in > > "object oriented C code"), add a suffix to your type (u8_t, struct > > my_class_t), then > > for instance you can nest structs, struct base_type_t base_type. > > * I personnaly add a macro #define loop for(;;) and use only 1 loop > > statement (hard rule) > > :/ Hard thruth
Re: [dev] Learn C
> * do not use enum (hard rule) > * do not use typedef (hard rule) > * use sized types: u8 u16 i64 float32 etc... you can use the C > preprocessor to fix that, but in some case, as a good tradeof (for instance > in > "object oriented C code"), add a suffix to your type (u8_t, struct > my_class_t), then > for instance you can nest structs, struct base_type_t base_type. > * I personnaly add a macro #define loop for(;;) and use only 1 loop > statement (hard rule) :/
Re: [dev] Learn C
On Sun, Mar 24, 2019 at 10:28:35AM +0100, Thuban wrote: > Hi, > I want to learn C. I mean, sane C. > What i read before was based on big IDE such as codeblocks. So, I don't > know how to write Makefiles from scratch. (just an example). > As an example, I found gobyexample [1] great. But it's go. > Any reading advice? Don't bother with makefiles yet, just use plain simple shell scripts. sane C = simple C. C has already a syntax way too rich and flexible. Most of the linux coding guidelines is nice. * do not use enum (hard rule) * do not use typedef (hard rule) * declare your variables at the beginning of a block (c99 allows declarations a bit everywhere, bad). personnally I try to keep my variables declared first, then the variables with assignment, because it's actually code (presume C initializers are code). * organise your code to _kind of_ * avoid more than 3 depth levels in a function * avoid too many variables in a function * keep roughly 80 columns code in order to have several readable columns on a "standard screen". * goto is appropriate in some cases * I personnaly add a macro #define loop for(;;) and use only 1 loop statement (hard rule) * try to stick to lower case identifiers * use sized types: u8 u16 i64 float32 etc... you can use the C preprocessor to fix that, but in some case, as a good tradeof (for instance in "object oriented C code"), add a suffix to your type (u8_t, struct my_class_t), then for instance you can nest structs, struct base_type_t base_type. * try to avoid as much as possible dependencies: Keep in mind the "technical cost" of your code, an optimizing compiler toolchain is extremely expensive (and all are turning into c++ garbage) * to help you "calibrate", read the "unix philosophies" out there (cf wikipedia). * complex code is not cool and does not make you smart: "The notion of 'intricate and beautiful complexities' is almost an oxymoron" (cf all c++ code and similar) * as a tradeof to avoid becoming a strong type extremist: view primitive variables as CPU hardware registers, so be carefull with your type casting. * always presume you will have to write a C preprocessor and compiler * keep your canonical SDK idiotic and simple * monkey patching is extremely bad (aka "corporate code") I certainly forget a ton of things, and tradeofs have to be done case by case. Nothing is set in stone. We all do mistakes. Keep in mind that we are all different, then we will draw "lines" not in the same way, but there is an absolute value which is true for all: the "technical cost" of your code and your deps (SDKs included). -- Sylvain
Re: [dev] Learn C
On Mon, Mar 25, 2019 at 10:08:28AM +0200, ab wrote: > Expect a thousand conflicting opinions. If you're truly interested in > programming, your best bet is to look at as many ideas as possible then > working on your ability to sort the bullshit out. "opinions" is the right term: subjective personal choices based mostly on personal tastes and context. In my previous email (which was not delivered by gmail yet because suckless mx was offline) I was talking about where you want to draw your "lines". Those "opinions" become bullshits when they increase in a significant way the complexity and number of dependencies of a stack of software components (SDK included): because this metric is mostly absolute, and this is why "suckless" exists. After 3 decades of programing, I am still discovering "bullshits": The last bullshit is python (kind of slowly replacing perl5, and I remember being a python fan boy a decade ago... pepe hands), and the one before was the "javascript web" and I quickly did figure out the c++/java/similar bullshit a long time ago. -- Sylvain
Re: [dev] Learn C
Expect a thousand conflicting opinions. If you're truly interested in programming, your best bet is to look at as many ideas as possible then working on your ability to sort the bullshit out. Good luck; you'll need it.
Re: [dev] Learn C
Yo. Maybe you wanna read this? https://git.suckless.org/ https://9p.io/sources/plan9/sys/src/cmd/ Regards Robin. On Sun, 24 Mar 2019 at 11:29, Thuban wrote: > > Hi, > I want to learn C. I mean, sane C. > What i read before was based on big IDE such as codeblocks. So, I don't > know how to write Makefiles from scratch. (just an example). > As an example, I found gobyexample [1] great. But it's go. > Any reading advice? > > Thanks. > Regards > > [1] : https://gobyexample.com/ > -- > thuban >
Re: [dev] Learn C
https://matt.sh/howto-c On Sun, Mar 24, 2019 at 10:28:35AM +0100, Thuban wrote: > Hi, > I want to learn C. I mean, sane C. > What i read before was based on big IDE such as codeblocks. So, I don't > know how to write Makefiles from scratch. (just an example). > As an example, I found gobyexample [1] great. But it's go. > Any reading advice? > > Thanks. > Regards > > [1] : https://gobyexample.com/ > -- > thuban >
Re: [dev] Learn C
Hi, I would recommend to simply to C projects. Suckless.org is great place to find sane C code with simple Makefiles. If you already are programmer, you should be able to learn C by just using it, no reading necessary. This way you should get a solid understanding of the basic quite fast and with time you will pick up one the more advanced topics. Regards Mattias Andrée On Sun, 24 Mar 2019 10:28:35 +0100 Thuban wrote: > Hi, > I want to learn C. I mean, sane C. > What i read before was based on big IDE such as codeblocks. So, I don't > know how to write Makefiles from scratch. (just an example). > As an example, I found gobyexample [1] great. But it's go. > Any reading advice? > > Thanks. > Regards > > [1] : https://gobyexample.com/ pgpZpqL1HYl4k.pgp Description: OpenPGP digital signature
Re: [dev] Learn C
Thuban wrote: I want to learn C. Kernighan and Ritchie, C Programming Language, 2nd Edition I mean, sane C. http://suckless.org/coding_style/ http://suckless.org/philosophy/ http://www.catb.org/esr/writings/taoup/html/ch01s06.html HTH, Stefan
Re: [dev] Learn C
Hi, K The C Programming Book Second Edition should be a nice book to learn C. On Sun, Mar 24, 2019 at 10:28:35AM +0100, Thuban wrote: Hi, I want to learn C. I mean, sane C. What i read before was based on big IDE such as codeblocks. So, I don't know how to write Makefiles from scratch. (just an example). As an example, I found gobyexample [1] great. But it's go. Any reading advice? -- Do what you like, like what you do. -- Pickfire
[dev] Learn C
Hi, I want to learn C. I mean, sane C. What i read before was based on big IDE such as codeblocks. So, I don't know how to write Makefiles from scratch. (just an example). As an example, I found gobyexample [1] great. But it's go. Any reading advice? Thanks. Regards [1] : https://gobyexample.com/ -- thuban
