There's nothing wrong with a DSL to do code gen. I much prefer it to overly complex templates or a mess of macros.
That said its easy to do wrong but that could be said about 90% of C/C++.
Examples:
(a) tHisisa_FuntTHAT_IMADE_pm(unsigned char a, unsigned char p).
(b) A function called do_nothing(), which contains a timer loop and a watchdog timer reset routine.
(c) rrunDAIG(), where DAIG is meant to be Diagnostics.
(d) Putting a watchdog reset in a 1ms timer interrupt. Tossers!
(e) About 200 files all up - 100% of which had names which meant nothing or were ambiguous.
(f) Functions put into random files.
(g) Extreme abbreviations like get_prdc_get_tm_sm() where the acronyms have no logical meaning.
(h) 5000 lines reduced to about 700 lines yesterday. Cut 'n paste kiddies.
(i) Up to 6 levels of Gets and Sets all over the place. Bloody Windoze OOP programmers.
(j) #defines without any case consistency. eg a_COnstant, A_constant, acon, Acon, whatever they wanted. You cannot easily depict a constant from a variable.
There's nothing wrong with a DSL to do code gen. I much prefer it to overly complex templates or a mess of macros.
That said its easy to do wrong but that could be said about 90% of C/C++.
Well, comparing a good DSL to typical templates or macros isn't much of a contest - and I'd agree with you. The problem is that most DSLs aren't good.
Usually they "start small" as a means of adding scriptability to a compiled application, and usually the reasons for that are bogus. Then something can't be expressed/done in the existing DSL, so a hack is added on. And then another. And another. And soon the DSL has grown like Topsy so that nobody, including the inventor, can quickly and intuitively grasp the interaction between all the misfeatures. (And I wouldn't dream of comparing that to C++, oh no)
And, of course, there is zero tool support since it isn't needed for a tiny add-on to the real application.
And you can't find anyone external with experience in myScrottyDSL so you have to train people. Except that anyone with an ounce of gumption won't want to tie their career prospects to a non-portable skill.
Contrast that with having a library expressing the same concepts. Tool support comes for free, developers already know the language and toolset so no training, and you can get the best rather than the dullards.
I once made the mistake of creating a scrotty little DSL for a 2 week job. I quickly realised I should just have used Forth (in that case), and vowed never to make a similar mistake again.
I have, however, repeatedly seen projects and companies spending many years going down the blind alley of custom DSLs - one to the extent that it actually killed the company!
There's nothing wrong with a DSL to do code gen. I much prefer it to overly complex templates or a mess of macros.
That said its easy to do wrong but that could be said about 90% of C/C++.
Well, comparing a good DSL to typical templates or macros isn't much of a contest - and I'd agree with you. The problem is that most DSLs aren't good.
Usually they "start small" as a means of adding scriptability to a compiled application, and usually the reasons for that are bogus. Then something can't be expressed/done in the existing DSL, so a hack is added on. And then another. And another. And soon the DSL has grown like Topsy so that nobody, including the inventor, can quickly and intuitively grasp the interaction between all the misfeatures. (And I wouldn't dream of comparing that to C++, oh no)
And, of course, there is zero tool support since it isn't needed for a tiny add-on to the real application.
And you can't find anyone external with experience in myScrottyDSL so you have to train people. Except that anyone with an ounce of gumption won't want to tie their career prospects to a non-portable skill.
Contrast that with having a library expressing the same concepts. Tool support comes for free, developers already know the language and toolset so no training, and you can get the best rather than the dullards.
I once made the mistake of creating a scrotty little DSL for a 2 week job. I quickly realised I should just have used Forth (in that case), and vowed never to make a similar mistake again.
I have, however, repeatedly seen projects and companies spending many years going down the blind alley of custom DSLs - one to the extent that it actually killed the company!I guess we just have different experiences, I find protobuf, flatbuffers and a few other DSL based code gen frameworks to be a lifesaver. It also depends on how you build your DSL, I find that ANTLR with either the C# or Java runtime to work particularly well.
Now writing your own DSL parser, that's the path of madness. If I'm building a project where I need to do a lot of boiler plate code(interop between C++/C# or other languages) I find DSLs to be a life saver.
...Does the project actually work?...
...Got any more juicy examples?...
Another line of code I found, which appears in a few similar ways in different files....
error_code = the_errorcode;
Thank is pretty bad. But what I am dealing with is much much worse. Seriously so.
Another line of code I found, which appears in a few similar ways in different files....
error_code = the_errorcode;
Let me guess... error_code has a global scope.
... except when you copy/paste, get the indentation wrong, and it still compiles perfectly.Python almost always complies perfectly and that's the problem.
C style commenting has the same problems (and solutions) as Python's indentation ...
Python also got a bit better than it was in the past, they stopped allowing you to mix tabs and spaces in indentation.
My problem is more with the lack of static typing (that is, a compile time constraint on the types of arguments and variables). It is less readable IMO and defers much of the type checking to runtime (assuming the the code is covered).
Last year I implemented an internal systems and did it in Python to speed up the development. After a week or so I realized that as the code becoming more complex the development slows and the code becomes less maintainable, so I rewrote it in Java and continued the development in Java.
Static typing is a very strong language feature.
I was skeptical, being a 25+ yr c programmer. at the end of the 2 weeks, I was pretty convinced that python is the Next Big Thing(tm)
I was skeptical, being a 25+ yr c programmer. at the end of the 2 weeks, I was pretty convinced that python is the Next Big Thing(tm)
I can sell you the Bay Bridge ;-)
I know of at least one Python project by a core Python developer that was rewritten in Java for maintainability. It's a glamorous scripting language, not the first and not the last.
http://en.wikipedia.org/wiki/Scripting_language
The language does not matter!
You can make poetry or garbage from any language, whether it be C, assembly, C++, C#, Python, JAVA or any other language.
The triple A attributes to writing good code is Attitude, Aptitude and Ability. If any of those are lacking, rubbish will be the result; you get high levels of all three from an engineer or programmer and you have a winner.
The language does not matter!
You can make poetry or garbage from any language, whether it be C, assembly, C++, C#, Python, JAVA or any other language.
The triple A attributes to writing good code is Attitude, Aptitude and Ability. If any of those are lacking, rubbish will be the result; you get high levels of all three from an engineer or programmer and you have a winner.
The language is not absolutely good/bad, but the language definitely does matter since it increases/decreases the probability of a good result....
The language does not matter!
You can make poetry or garbage from any language, whether it be C, assembly, C++, C#, Python, JAVA or any other language.
The triple A attributes to writing good code is Attitude, Aptitude and Ability. If any of those are lacking, rubbish will be the result; you get high levels of all three from an engineer or programmer and you have a winner.
The language is not absolutely good/bad, but the language definitely does matter since it increases/decreases the probability of a good result....Agreed, the language matters to some extent, but is a poor second to the three A's. At the moment I am working with refactoring coding mostly in C where 4 of the 5 predecessors had at least 1 of the 3A's missing and a maybe a few screws loose as well. However, one predecessor was very good and wrote crisp clean efficient C code, easy to follow and beautifully commented.
That programmer included some AVR assembly language files, three which I came across today when I noticed that my Windows 7 sees a .asm file, it calls the file "Assembler source file". There is no such language as assembler and there never has been. The correct term is assembly language. Notepad++ used to call assembly language "assembler" until I got the authors to change it around version 4. I am not sure whether it is Visual Studio, AVR Studio, some other compiler or Windows Explorer incorrectly identifying the .asm file.
a lot of what you just said is all based on TOOLS issues, not so much language issues.
with a good ide, all languages are refactorable and you can find refs to functions, vars, externs, etc.
a lot of what java fans think is good about java is quite often about the ide they learned on!
don't get me started about makefiles (their equiv) on java. what a horrible mess! makefiles in c have been around so long, its a proven technology and not hard to master. ant and other build systems for java are horribly complex and take a long time to learn to do them well.
I love that python has no build system and no need for it. no compilers, and yet it runs very fast if you do things in the proper pythonic way
c++ always annoyed the hell out of me. I love C since its been around forever, its used to write os's, networking stacks and most of the unix cmds you use every day. for scripting, though, I am migrating from bash to python. java was an interesting experiment, but I consider it like pascal: great to learn stuff on, but I hate having to support other peoples' code when they use java. and its mostly the new generation that insists on java; us oldtimers still mostly reject it (personal experience working in the bay area, fwiw).
I learned computing using Algol-60 on 5-channel paper tape. (Consider how you can represent digits, letters and symbols in 5 bits.)
I find it about as absurd to compare Python, Java, and C as it would be to compare a can opener, scissors, and chainsaw.
Giving up Bash scripting for Python is a good move. Giving up C for Python is not. Python is a scripting language, like Perl, and is really good for quick-n-dirty tasks, or minor applications. For whatever reason it's the darling of developers right now, but you wouldn't write a device driver in Python, or a kernel, or an embedded application. Wrong tool.
C is really the sweet spot between ASM and Java / Objective C / whatever, and despite a LOT of en-vogue languages coming and going through the years, it's still ubiquitous.
Yeah, void* can be a pain in the butt, however the times you use void* should be relatively few and far between. And in such cases, there should be no obviously preferable way to handle it. It's a very sharp knife, so don't be careless with it. Hopefully you're not using it for a tight loop's index, so optimization of a raw pointer shouldn't be so critical anyway. Most of the time, you're dealing with char, int, structs, and pointers to the same. In those cases, the code you compile probably can't get any more optimized. (Just ask the guys in the 1 Minute thread.)
Anyway, Java is pretty big, and if it's going to be unseated, it won't be by Python. For e.g., the US government relies on Java pretty heavily for web services and such. No one's going to be tossing out all that enterprisey app server stuff for a scripting language. C'mon...
I learned computing using Algol-60 on 5-channel paper tape. (Consider how you can represent digits, letters and symbols in 5 bits.)
Me too! On an Elliott 803. 8k words of 39 bits each. Hardware floating point. Ahhhhh....
I do Java and C# if I have to, but C is my real home.