orangeduck

Yeah split stacks will be a problem. Essentially `tgc` just scans between the address recorded as the "bottom" and the one recorded as the "top". Both of theses can be manually adjusted if you have some better idea of these locations (such as your own spaghetti stack).

The registers are flushed to the stack before the mark is performed (using `setjmp`) so unless the behaviour of the platform is particularly odd in this case it shouldn't be an issue.

For anyone curious, I built a project in C called tgc (https://github.com/orangeduck/tgc) which has some similarities. It's essentially a stand alone version of the Cello Garbage Collector (http://libcello.org/learn/garbage-collection) and provides garbage collection for stack and heap objects allocated via the given functions.

I really like this idea, but bezier curves are quite computationally difficult to use. There are many representations of these kind of continuous shapes which are much easier for this kind of processing.

For example I would try converting the bezier representation into an implicit HRBF representation (here is a good explaination in 3D http://rodolphe-vaillant.fr/?e=12). This representation should be much easier to process on the GPU - checking how much the point is inside/outside the glyph should only be one matrix multiplication which would make the computation in the actual shader really really fast.

Lua has an alternative to Regex which is an extension of the C patterns (used in printf etc).

http://lua-users.org/wiki/PatternsTutorial

At first I found it a bit confusion but they're actually pretty great. For me at least 90% of the tasks I want to do with regex can be done with scanf, and Lua's little extension covers the remaining 10% quite well.

I know lots of people often say that it would be nicer to use functional composition for regex instead of strings because strings are too confusing, but I disagree with this. The confusion of regex to me is not from the string representation, it is that some characters are "special" while others are "normal" (including whitespace). At first it appears that most characters are "normal" and so you can start from some example and generalize the string until it matches all the things you want - but once you start putting parenthesis and such in you start to realize that most of the string wont be matched "normally" and it is better to start thinking like a grammar and write it from scratch. This double thinking is pretty annoying.

For this reason, to me the Lua patterns are really the only alternative I've come across to regex that I've liked. They've got nice compact expressive syntax, can really easily do most of the matching tasks I need due to the scanf base, (almost) all the "special" characters begin with %, and the complex cases can still be matched.

It uses raw pointers (void*) and something a little like a vtable: http://libcello.org/documentation/hacking

Author here. I always get asked two questions about libCello.

1. Why? 2. Is anyone using it for anything serious?

The second one is easiest to answer: no. And most people are suprised to hear that I probably wouldn't use it for anything serious either.

If you hadn't noticed from my github page I love C, and while I am also very interested in the things Cello adds such as duck typing and interfaces, and all the syntactic sugar that makes thing really nice and literate; it doesn't interest me enough to choose it over C. Additionally who is going to want to use my project if it uses this weird hacky C library! People are (for good reason) very suspect of dependancies.

That isn't to say I don't like programming in Cello. I'm almost definitely the person who has written the most in it and some things are just a joy to write in it, and look so clear and functional and algorithmic. At some point in the distant future when I find the time I really will attempt something serious such as a web framework. If that takes off we seriously can decide if it really is a good project (hur hur hur).

To be fair, "why" can also be pretty easy to answer depending on who is asking: because I could. Because I thought it was kinda cool and that people would be interested. There seems to be some default position in programming that unless your project is silly or sarcastic people assume you are "advocating" something by doing it, or making some kind of political statement on software development. I didn't work on this project to try and change the world. Nor to create something better than the alternatives. It doesn't change my life if people use Cello or not. I wasn't frustrated with C++, and I wasn't looking for a cylindrical rolly thing for my cart. I just made it for fun.

Thanks for the support, and congratuations to yourself on publishing. It looks like you've done a really great job and totally nailed the process and the print version!

> How did it end up working out? I assume it's process, not spot color. Is the colored text still sharp enough to be read easily?

Yeah it isn't spot color and the text looks really great and easy to read. The print quality of the interiour seems very high quality and it really makes it seem alive with the images and colored sections. I think it keeps it fun to read, which was always one of my intentions. I was totally over the moon with the interiour when the first proof copy arrived.

But as you mention financially it isn't going to make much sense. I don't make much more off the print book than the ebook sale, and yet it costs the consumer ten times as much! So in some sense it was kind of vanity project - but I still enjoyed it a lot, and wanted to prove I could do it additionally.

> It worked out well for me -- the time I spent in InDesign was really enjoyable -- but I can definitely see how it wouldn't be the right choice for others.

Actually if someone had mentioned InDesign to me I might have given it a try. I mainly picked Latex because I knew the font rendering and formatting would be awesome and it was something I knew already so I could get started. As you say, InDesign is fun, while working on a complex project in Latex isn't exactly a joy. But I think the end product was still sufficiently professional :)

> I've done some print work before, so I was fully expecting some variance here. Unless you have a carefully calibrated display and keep track of color profiles through the whole pipeline (and they do too), there's always some difference.

Yeah I probably should have been prepared for this. And additionally there was some error in how they were cutting the bleed which looked poor with my cover design. If I did it again I would definintely try to find a professional to consult before tacking the cover for any friendly advice he/she had to offer.

> For what it's worth, I'm really glad you made it, and I'll be buying a copy.

Thanks! I feel bad ending on a downer because I really have gotten a lot of pleasure out of it, so I don't want to paint the process in a negative light. As a learning experience it was really unique and great. There are just too many fun, great and unique areas of computer science to play around with as well!

I've also recently self published my book http://www.buildyourownlisp.com/ via createspace, having first converted it to an ebook and then to a print book, so I was really interested to see this article to read what was the same and what was different. I did speak to a couple of keen publishers, and I guess ended up self publishing for similar reasons. I wanted more control over the process and the final layout, and some publishers were not happy with having a free version provided online.

Creating the ebook was fairly easy. It ended up being a case of writing a bunch of scripts to fix and tweak various things about the HTML website. Constructing the print book was a lot harder work.

I explored rendering a PDF from the ebook but the font rendering was ulitmately too poor and the configuration of the ebook tools was getting really difficult. Additionally the text layout was not great with lots of code blocks getting split over pages and images in wrong places.

I knew I needed to use a program more suitable for publishing so I tried doing a manual conversion to Latex, but after the first couple of chapters I realized it was going to take too long. Instead I begun on some scripts converting my HTML into Latex automatically. Most of this work was done by `pandoc` and a list of regexes that redefines "unholy". God only knows how it all worked in the end. I found various Latex solutions for the pullouts, and syntax highlighting, that I liked ang which gave me as much control as I required, and in the end it was actually looking pretty nice.

Then came the copy editing, and like in this article it was long, tedious, difficult, and I'm still not completely 100% happy with the final result. It took the form of a bunch of scripts inserting pagebreaks before or after paragraphs and moving text, images and pullouts to balance the pages. Essentially it is very difficult to copy-edit a book with so many code blocks, even with the help of Latex. This is the only part of the process where I felt down on my skills, and that someone who does it for a living would not face the same problems (probably they wouldn't be using Latex in the first place). But in the end I was happy with the interiour - which still looked awesome printed in color - and I think I by far did the best I could.

I designed and made the cover in Photoshop to the vision of it I had always had. I think I did a fairly decently job but certainly it would have been better looked at by a professional. Unfortunately createspace doesn't seem to do a good job of printing the cover, so it didn't look precisely like the supplied image I made. Perhaps this is different when ordering non-proof copies.

The nice thing about my approach was that when people send pull requests and corrections to the website I can automatically integrate them across the ebook and print versions, and if I ever do want to make updates in future the process is relatively painless. I think I'd be happy to self publish again. Createspace was great and I felt good not having to rely on others for the process. The main thing I didn't like about it was the marketing - that is something that does not come naturally to me. I think it is unlikely I will write a programming book again. It was fun, but I felt like finishing it more of an obligation once the ball was rolling. Ultimately I think I made a "good" thing which lots of people read, enjoyed and appreciated, and I know it wasn't just an additional item of waste in the universe due to all the people who have reached out to me personally (thank you so much). But at the end of the day unfortunately it hasn't derived me satisfaction worth the effect it took to produce - which was a lot - and I think that is just due to the nature of the thing, not it's success or position in the world.

I'm a big advocate of "worse is better" - in fact I put it in my bio even at the risk of scaring off potential colleagues or employers. The real meaning of "worse is better" is of course subjective and complicated. And as has been pointed out in these comments, "worse is better" is not about creating "worse" software and then marketing it as "better". It is something much more philosophical.

In my eyes "worse is better" is about the mindset of approaching a task. It is about diving right in and learning through production - without being paralysed by the idea of introducing hacks or ugly design. It is the idea that, for the moment, there isn't a need to be worried about covering every edge case or possible failure option. It persuades you to focus on something simple and easy to explain, with a single purpose or intent. It is better to produce something (anything) and see where it takes you.

It also says how important it is to embrace contribution and collaboration. How important it is to, after some threshold, release yourself from feelings of ownership.

But if I had to nail down exactly why I believe "worse" is so successful ("better") it is because those that create "worse" software don't focus on the software - they focus on the idea. From that the software is painfully drawn. The software might suck, but I believe ideas are better. They are more persistant, easily explored, dynamic, and shareable than software. Ideas that are good, simple, and easily taught are far more important than well designed software. That is why they survive.

There are lots of programmers and hackers who don't believe in "worse is better". Sometimes you seen them on HN with a fantastic new programming language (or something) they have designed and built in isolation - perfect in every aspect (at least to them). Nothing quite hurts like their confusion when interest dwindles and their software is forgotten. All they had seen on HN were "worse" links every day, and after years they had provided "better" - to them it is criminal that it hasn't been picked and gained momentum.

Worse is better is not going away, and I think you can either engage yourself in it as a philosophy, or struggle.

I think this demonstraights a real weakness of Haskell. Several times I've started a new project only to spend several hours trying to work out the correct way to structure what I want. Often it is hours before I even get my first successful compile. This is exactly as shown in this blog post. While some people enjoy this kind of tinkering, for me this really quickly saps all my motivation for the task. I just want to get something, anything, working. I work best jumping directly into a task and understanding it from the inside out, learning from my mistakes. Sometimes if I do find a quick and dirty way to get something working in Haskell - often refactoring it also becomes pretty difficult - which turns me off again. Neither of these are problems I have in other languages.

Arguments for which approach is better aside, it is no wonder lots of people who learn and approach tasks like me, feel a little betrayed by Haskell. I've used it for a bunch of things, I'm past the steep learning curve - but it seems I'm still not reaping the rewards. Is my philosophy of jumping into projects really so bad? Is it Haskell's place to question such an approach, when it has served me so well elsewhere?

Macros in C can sometimes be nasty, but "min" is a pathological case for a macro because it isn't what macros were meant for.

In reality "min" should just be a function, and you should write a separate function for each type you want to define it over. This is how this problem is solved in C, and almost all other languages. It just looks deceptive because C's native operators like "<" and ">" happen to be generic across some number types. This is just for convenience, it isn't how C is meant to be programmed. Pretty much every other language also makes you define different implementations of functions when you have a different type you want it to work on. Lots let you type the same function name, independent of the type - via generics, interfaces, or type-classes - but all call out to different implementations at the end of the day. Very few can derive those implementations.

As far as I am concerned, Macros in C are best used just to save on typing. They get a lot of hate because the syntax looks like functions - so people try to use them as functions. I don't recommend using them as functions, instead use them to save typing - because saving typing and avoiding repeating yourself can only reduce errors.

So I get it, and it makes a good point, but this could be more of a symptom than a disease.

When I first started programming C I also tended to just exit the program on getting a bad return code, because I'd never been taught how to properly handle errors - I'd always just replied on exceptions.

Only later did I start to get bitten, and take proper care to handle errors sensibly and explicitly.

As "go" is such a new language I wouldn't be surprised if a similar thing has happened to new programmers migrating over to it.

Anyone who likes this idea but wants to do it in C might enjoy this http://www.buildyourownlisp.com/

Hi crnxion. The source can be found here: https://github.com/orangeduck/BuildYourOwnLisp

I welcome corrections/edits.

Thanks. I've fixed the link.

Author here. A parser combinator library is used to do the parsing.

Thanks for the suggestion. I'll open this option up if possible.

I wrote this book over several months. It took a few days to get the courage to share it online. It probably took you about 20 seconds to not read my book, dismiss it, and post a comment telling other to do the same. If you think an alternative is better that's fine, but how about you take an extra 20 seconds to think about the situation next time you are going post a comment.

Author here. Actually a parser combinator library is used for the parsing. As you mention, I think there should be some interesting things inside for people with any experience in C.

If you understand the difference between snprintf and sprintf, what trouble it can cause, and where to use it, it sounds like you're already doing great. What would be bad was if you had the blind notion that "snprintf is good" and "sprintf is bad" without knowing why.

As for an example of when you might want to use sprintf. If you compile to C89 (ANSI) snprintf isn't included in the standard so you're left with sprintf if you want your code to be portable.

A better example is strcpy though. A function which is completely normal and safe when used correctly, but someone with the wrong idea might use strncpy as a "safer" version and cause themselves more trouble for not knowing what is going on. As if to prove my point you can see someone advocating this exact thing in another comment tree in this thread. They've probably heard from someone that the "n" version of functions are safe. If they'd actually looked into it they'd realize strncpy doesn't do what you might think.

Half the people in this thread seem to have missed the point. This article is not supporting 100% abstinence of these functions. It is doing exactly the opposite - and showing up people who say "never do this" or "that is always wrong" as being as ridiculous as those who blindly support abstinence from sex. This kind of tunnel vision, learning by rote, and refusal to teach what is really happening, is exactly the same stupid attitude that creates bad programmers, as it creates unbalanced teenagers.

Perhaps, just like condoms, memcpy, strcpy, strcat are dangerous or ineffective 10% of the time. But that other 90% of the time, when used correctly, they are perfectly safe, fun and essential to learning and growing. Avoiding them completely does not create a healthy relationship between a language and its programmer. I realize that not everyone in this thread is a C programmer, but this prevailing attitude of saying "this should never be done/used" just because you're heard that from someone else, is a really petty, annoying, and persistent aspect of programmer culture.

This is a great article. I relate to Jonathan Franzen in his mission to get others to seek out the one-to-one relationship he had with Kraus. I believe this relationship is really what the whole piece is about.

In many of his points he is true. The conventional means of seeking this same fulfillment are sinking away.

But he overestimates how much people are nullified by technology. And he is blind to the other possible means of access to these feelings technology can provide. Technophobes can't see behind the veil of pixels. They believe that all experiences on a computer are fake, and that the internet is a superficial control panel onto a (boring) machine of cogs and wires. A computer is no more than a stone to throw in a river.

The problem is these people rarely look. And when they do their self fulfilling prophesy dirties their own great experiences (they believe the computer in its wisdom has tricked their emotions). Anyone who has spend years on a forum, or late nights on IRC talking to people they've known for decades, knows these experiences are real.

To engage with technology is the only way to re-find these experiences in the modern world. It isn't really anything to do with technology. It embodies all aspects of life. To anyone growing with hate about the world I give the same advice _engage_ and you will find what you're looking for.

Author here. Yeah the syntax looks much better with correct highlighting. I've provided a custom definition for Notepad++ on the repo - and of course there is the definition used on the website too.

I'm also a big fan of DSLs and would love see some of the things you mention. My next (fun) big project is actually not so far from the same lines ;)

Many thanks to everyone for the kind comments! It really is encouraging. :)

As an idiom I quite like this form. I often do similar for double iterations:

   for (int x = 0; x < width; x++)
   for (int y = 0; y < height; y++) {
      do_something(x, y);
   }

Notepad++ also has a spell checker which is pretty decent and afaik supports other languages.

This is an excellent explanation.

As you say, if we assume that my set of macros are the machinery, then truly my "BRAINFUCK()" macro is Turing complete.

Using this distinction between language and machine, how peculiar that a Turing Complete thing can be expressed using a language which is not Turing Complete itself.

The question is really - are these distinctions between machine and language always meaningful and without contradiction.

Yeah using $ was pretty cheeky. I use a few other GCC specific features such as nested functions, which is why I specify that the standard is GNU99 rather than C99. If you have any errors on mac please post a bug report as I don't have a machine to test on! Thanks.

This is correct. "Table" is a datatype which copies the values into the table, while "Dict" is a data type that holds references to the objects. The same semantics hold for "Array" and "List".

Although not perfect this was probably the best way I could have designed such structures. There is some info in the header files as to how to use them.

That's a lot of questions. I will do my best to answer them but note I am not trying to sell a language here. I'm just a student and wanted to show an interesting project I'd been playing with.

The performance implications are much like vtable lookup in C++. Generic functions are essentially overloaded and their function pointer looked up at runtime. The main tradeoff over C++ is that rich types don't play well when allocated on the stack as destructors cannot be automatically called on frame exit.

The added semantics are not optional, but you can still program in standard C while avoiding the defined keywords and functions and the interaction should not be troublesome at all. There is no price for linking the library.

It is not type-safe and employs runtime type checking where inserted by the user - but also this allows for duck typing and more generic code so perhaps it is not a bad thing all round.

I hope that helps. Any more questions feel free to drop me an e-mail.