Naming of the title reminds me of the best C book I've read, "Expert C Programming: Deep C Secret" by Peter Van Der Linden.

https://g.co/kgs/Gyvg69

Although I don't use go (yet), I can see the benefit of this mechanism as I use a similar one for my own c/c++ code. There I use specially tagged comments to embed python in the c/c++ sources, and then run all the code through a python interpret stage to expand/execute the python code before compiling it. Actually it supports C macro style for the embedded code, which is a bit more sensible than misusing code comments.

For example for generating a c/c++ enum:

    enum example_t
    {
        #py \
        for line in open('values.txt'): \
            print('EXAMPLE_' + line.strip() + ',')
        EXAMPLE_Max,
        EXAMPLE_Unknown
    };

Or alternatively to stuff it in a comment:

    enum example_t
    {
        /* py
        for line in open('values.txt'):
            print('EXAMPLE_' + line.strip() + ',')
        */
        EXAMPLE_Max,
        EXAMPLE_Unknown
    };

If anyones interested, heres the python script I use to preprocess the c/c++ files https://github.com/hartcw/cppy

Sure the concept is definitely useful. But overloading comments seems monumentally dumb.

They should have copied Java's annotation model which makes a lot more sense.

That's a valid thing to do in C++ because the language doesn't support alternatives. And you can't really expect it to, because C++ has tried various things over the years that make this much harder to add ex-post facto. However, it's worth noting that using such tooling in C++ can cause more problems than it solves if you aren't careful. This is just one of the ways C++ is showing its age.

These problems are exactly why this is unacceptable in Go. Go has the benefit of learning from C++'s mistakes and seeing other attempts at solutions to the problem. Language designers have made these mistakes before, realized they were mistakes, and come up with better alternatives. This is just another example of the Go team either being unaware of or ignoring decades of development in programming languages.

As long as you're making it seem like C / C++ code, but isn't, and will break if you treat it like C / C++ code, why not actually extend the syntax?

Something like PY_CODE(<blah>), for instance. That way it won't compile unless you run it through the preprocessor.

Interesting. Why don't you use an include file directive there?

    enum_example_t
    {
        #include "example_values.txt"
        EXAMPLE_Max,
    } 

where example_values would have the strings 'EXAMPLE_foo,'? Just wondering.

The way the license information is presented is a little misleading. The Community edition is described as for 'Open Source & Hobby Projects', giving the impression that its not possible to release a commercial product using that. Thats not true of course, its LGPL licensed and so can be used for commercial software as long as the license obligations are adherred to.

The desktop app I sell uses Qt, against the LGPL license. I would probably pay for the commercial license from them if it was more reasonably priced, but $295 per month to distribute on Mac and Windows is just too much to swallow.

>Thats not true of course, its LGPL licensed and so can be used for commercial software as long as the license obligations are adherred to.

What are those obligations? Can you summarize or give a link? Thanks.

Roughly: link dynamically or provide object files for relinking; don't prohibit reverse engineering of your software (for compatibility with new library versions); don't modify the LGPLed library to require a proprietary component to function.

Thanks, JoshTriplett and FigBug.

Dynamically link to all Qt libraries. Release all changes made to Qt source code.

I missed that subhead and I agree. As long as you dynamically link against the library it's perfectly fine to use it for commercial apps.

Why would someone need/want to use Qt by not dynamically linking the library. I've never understood Qt's business model or what I can and cannot do with it. I just use pyside on my pet projects.

I believe you would purchase Qt for the training and support options, and not so much for hiding a couple of DLLs in the deliverables.

I develop and sell Smart Shooter.

http://kuvacode.com

Its a traditional desktop app (windows, mac), but only sold online via our own website or the mac app store. I created it about 4 years ago, and work on it solely in my spare time. In fact I'm employed full time at a major tech company but this I keep separate.

To claim its profitable is a bit misleading, because of cause the major cost in developing such software is my own time. I've incorporated as a limited company here in Finland but do not pay myself a salary, so the only costs to the business are web hosting and occasional hardware purchases (computers, cameras).

I started this as a project for personal interest; at the time I was working as a software engineer developing financial trading software. Smart Shooter was a good way to develop something that covered both my interests in graphics programming and digital photography, to alleviate the borebom from my day job.

So for me its been successful, its still an pleasureable hobby, allows me an excuse to play around with the latest cameras, and brings in some pocket money. It doesn't generate enough revenue that I could quit my main job, but the possibilities could be there if situations change.

I use TCL in a consumer app that I develop, to allow users to load and run scripts that control the behaviour of the app. Its for controlling cameras (smart shooter), and actually I usually end up writing the scripts for my customers. But its amazing what you can achieve quickly and easily due to how flexible TCL is, users are amazing when I email back a custom script for some fancy HDR photo bracket the same day they request it!

And I myself am surprised at how many photographers have managed to write their own scripts, even non-programmers. I've been thinking about adding support for python as the scripting language, but I can't justify it just for been fashionable.

Looks impressive so far, I've basically been doing this kind of thing manually in gmail using labels, for supporting Smart Shooter.

So its free for now whilst in beta, I just might be hooked by the time they start to charge for it..

I run a UK based company, and use three different 'Buy buttons' on my website - that is: 1. Paypal 2. Google Checkout 3. Fast Spring

I've not had any problems with any of them. Paypal and Google Checkout are comparable in price, I think its about 4% cut.

FastSpring is a bit more, about 8% I think, but it has the benefit of handling tax complications - ie. it checks where the seller is, and charges VAT accordingly. Plus it handles currency conversion so the buyer can pay in their local currency.