Programmers must...
-
I love articles like this[^]. FUD. * I saw the author of Ant at a conference recently and he, quite sadly, noted how his tool had been somewhat perverted. He specifically mentioned how he disagreed with the functionl concepts that had been put into Ant's XML dialect (e.g. conditions.)
regards, Paul Watson Ireland FeedHenry needs you
eh, stop bugging me about it, give it a couple of days, see what happens.
-
I love articles like this[^]. FUD. * I saw the author of Ant at a conference recently and he, quite sadly, noted how his tool had been somewhat perverted. He specifically mentioned how he disagreed with the functionl concepts that had been put into Ant's XML dialect (e.g. conditions.)
regards, Paul Watson Ireland FeedHenry needs you
eh, stop bugging me about it, give it a couple of days, see what happens.
He complained about all that, yet failed to mention XMLRPC and SOAP .... Personally, I don't see too much wrong with using XML in such ways. It is far better than having 15 million different compilers/interpreters running around because each and every programmer decided to make their own to load in whatever data/script/whatever they needed for their application.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
I love articles like this[^]. FUD. * I saw the author of Ant at a conference recently and he, quite sadly, noted how his tool had been somewhat perverted. He specifically mentioned how he disagreed with the functionl concepts that had been put into Ant's XML dialect (e.g. conditions.)
regards, Paul Watson Ireland FeedHenry needs you
eh, stop bugging me about it, give it a couple of days, see what happens.
Learning how to build compilers is, unfortunately, too difficult. The most widely used textbook, Aho, Sethi and Ullman’s “Compilers, Principles, Techniques and Tools,” is a classic example of everything that’s wrong with academic writing. Its thorough, but impenetrable, coverage of the subject offers virtually no practical information. The academicians love it, but I’d recommend avoiding the book unless you have a strong mathematical background and are interested more in the underlying math than practical application.
whew.. glad it wasn't just me. i bought that book thinking i'd like to write a little scripting language for one of my apps. i found it easier to re-invent LISP from scratch.
-
Learning how to build compilers is, unfortunately, too difficult. The most widely used textbook, Aho, Sethi and Ullman’s “Compilers, Principles, Techniques and Tools,” is a classic example of everything that’s wrong with academic writing. Its thorough, but impenetrable, coverage of the subject offers virtually no practical information. The academicians love it, but I’d recommend avoiding the book unless you have a strong mathematical background and are interested more in the underlying math than practical application.
whew.. glad it wasn't just me. i bought that book thinking i'd like to write a little scripting language for one of my apps. i found it easier to re-invent LISP from scratch.
A better/easier/more appropriate book for this is John Gough's Compiling for the .NET Common Language Runtime[^]. The Dragon book broke my little head in Chapter 1, but Gough's book got me almost understanding it. Gough, and his grad students, were responsible for a lot of the early non-Microsoft .NET languages.
-------------- TTFN - Kent
-
I love articles like this[^]. FUD. * I saw the author of Ant at a conference recently and he, quite sadly, noted how his tool had been somewhat perverted. He specifically mentioned how he disagreed with the functionl concepts that had been put into Ant's XML dialect (e.g. conditions.)
regards, Paul Watson Ireland FeedHenry needs you
eh, stop bugging me about it, give it a couple of days, see what happens.
Paul Watson wrote:
* I saw the author of Ant at a conference recently and he, quite sadly, noted how his tool had been somewhat perverted. He specifically mentioned how he disagreed with the functionl concepts that had been put into Ant's XML dialect (e.g. conditions.)
When I was first starting to write NAnt scripts, I came across the conditions and thought "wtf? Why would anybody want to do this?" I'm glad I'm not the only one who thinks they're stupid.
Once you wanted revolution
Now you're the institution
How's it feel to be the man? -
He complained about all that, yet failed to mention XMLRPC and SOAP .... Personally, I don't see too much wrong with using XML in such ways. It is far better than having 15 million different compilers/interpreters running around because each and every programmer decided to make their own to load in whatever data/script/whatever they needed for their application.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
Zac Howland wrote:
Personally, I don't see too much wrong with using XML in such ways.
Agreed. What difference does it make "what" you are interpreting. If one interpreter is not appropriate then likely none are, at least without a JIT compiler to go with it. Customer: "I'd like one interpreter please." Clerk: "Would you like a JIT with that?"
led mike
-
Zac Howland wrote:
Personally, I don't see too much wrong with using XML in such ways.
Agreed. What difference does it make "what" you are interpreting. If one interpreter is not appropriate then likely none are, at least without a JIT compiler to go with it. Customer: "I'd like one interpreter please." Clerk: "Would you like a JIT with that?"
led mike
Or just make it a pure compiler and generate an executable script (which will be very unreadable and only maintainable through the source script that was used to generate it) to do things like Nant scripts do ;P
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
A better/easier/more appropriate book for this is John Gough's Compiling for the .NET Common Language Runtime[^]. The Dragon book broke my little head in Chapter 1, but Gough's book got me almost understanding it. Gough, and his grad students, were responsible for a lot of the early non-Microsoft .NET languages.
-------------- TTFN - Kent
Thanks for your recommendation. I have a compiler project starting soon and I was going to buy the dragon book. Now I will take a look at Gough's book.:)
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
-
I love articles like this[^]. FUD. * I saw the author of Ant at a conference recently and he, quite sadly, noted how his tool had been somewhat perverted. He specifically mentioned how he disagreed with the functionl concepts that had been put into Ant's XML dialect (e.g. conditions.)
regards, Paul Watson Ireland FeedHenry needs you
eh, stop bugging me about it, give it a couple of days, see what happens.
Wow. Either he's right, and a lot of people are misapplying XML, or he doesn't have a clue as to how flexible, manageable, platform independent, schema driven, XML can be, especially when used as an internal format that people never see. Strangely, I think he is both right and clueless at the same time! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Learning how to build compilers is, unfortunately, too difficult. The most widely used textbook, Aho, Sethi and Ullman’s “Compilers, Principles, Techniques and Tools,” is a classic example of everything that’s wrong with academic writing. Its thorough, but impenetrable, coverage of the subject offers virtually no practical information. The academicians love it, but I’d recommend avoiding the book unless you have a strong mathematical background and are interested more in the underlying math than practical application.
whew.. glad it wasn't just me. i bought that book thinking i'd like to write a little scripting language for one of my apps. i found it easier to re-invent LISP from scratch.
Awesome. That's a required book for my compilers class this quarter. Fantastic. Chris, have you ever studied stuff like finite state automata, context free grammars, etc? Or did you jump into the book without that sort of foundation?
Once you wanted revolution
Now you're the institution
How's it feel to be the man? -
Awesome. That's a required book for my compilers class this quarter. Fantastic. Chris, have you ever studied stuff like finite state automata, context free grammars, etc? Or did you jump into the book without that sort of foundation?
Once you wanted revolution
Now you're the institution
How's it feel to be the man?David Stone wrote:
Chris, have you ever studied stuff like finite state automata, context free grammars, etc?
yeah, i had a ton of that stuff in college; but that was 15+ years ago. when i tried that book for my own purposes, a couple of years ago, it just wasn't very helpful. IIRC, it gets very abstract and theoretical, very quickly, without a lot of practical examples. and, i needed something to help me write an interpreter for a simple text processing language for an HTML template system (so the user could add little bits of code to manipulate program data and stuff it into the template). this book goes far beyond what i thought i needed. maybe if i was going through it in a classroom environment with an instructor and exercises, it would've been better for me.
-
Or just make it a pure compiler and generate an executable script (which will be very unreadable and only maintainable through the source script that was used to generate it) to do things like Nant scripts do ;P
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
Zac Howland wrote:
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Ha ha ha ha! :laugh:
-
David Stone wrote:
Chris, have you ever studied stuff like finite state automata, context free grammars, etc?
yeah, i had a ton of that stuff in college; but that was 15+ years ago. when i tried that book for my own purposes, a couple of years ago, it just wasn't very helpful. IIRC, it gets very abstract and theoretical, very quickly, without a lot of practical examples. and, i needed something to help me write an interpreter for a simple text processing language for an HTML template system (so the user could add little bits of code to manipulate program data and stuff it into the template). this book goes far beyond what i thought i needed. maybe if i was going through it in a classroom environment with an instructor and exercises, it would've been better for me.
Chris Losinger wrote:
maybe if i was going through it in a classroom environment with an instructor and exercises, it would've been better for me.
We'll see. The class syllabus isn't up yet, so I'm not quite sure what we're going to be covering. It'll be interesting to see how it pans out.
Once you wanted revolution
Now you're the institution
How's it feel to be the man? -
He complained about all that, yet failed to mention XMLRPC and SOAP .... Personally, I don't see too much wrong with using XML in such ways. It is far better than having 15 million different compilers/interpreters running around because each and every programmer decided to make their own to load in whatever data/script/whatever they needed for their application.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
But XML is only a way of formatting, and provides a toolset for data forward/backward compatibility. Without the schema definition, it's as random garbage as any other invented language. And whether Schema XML is more readable than EBNF - the vote is still out.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify! || Fold With Us! || sighist -
Zac Howland wrote:
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Ha ha ha ha! :laugh:
He's right and I'm not laughing {sigh}. s: Another software (and more) engineer.
-Bri "The most deadly words for an engineer. 'I have an idea.'"
-
Learning how to build compilers is, unfortunately, too difficult. The most widely used textbook, Aho, Sethi and Ullman’s “Compilers, Principles, Techniques and Tools,” is a classic example of everything that’s wrong with academic writing. Its thorough, but impenetrable, coverage of the subject offers virtually no practical information. The academicians love it, but I’d recommend avoiding the book unless you have a strong mathematical background and are interested more in the underlying math than practical application.
whew.. glad it wasn't just me. i bought that book thinking i'd like to write a little scripting language for one of my apps. i found it easier to re-invent LISP from scratch.
Well don't feel too bad. The book was mis-titled from the get-go. Engineers are practical folk and look for techniques and tool kits. Computer scientists, OTOH, frequently aren't. They are big into theoretical underpinnings with massive amounts of logic and mathematical proofs to make their case. I'm from both worlds, started as a statistician and computer scientist, made my living as a multi-disciplinary engineer/analyst. I'll take the engineering/analysis side any day of the week although sometimes when I'm feeling mellow, I'll grab a theoretical text in some field and curl up with it. It takes both kinds to make the world go around.
In other words, they should have stopped at "Principles".
-Bri "The most deadly words for an engineer. 'I have an idea.'"
-
He complained about all that, yet failed to mention XMLRPC and SOAP .... Personally, I don't see too much wrong with using XML in such ways. It is far better than having 15 million different compilers/interpreters running around because each and every programmer decided to make their own to load in whatever data/script/whatever they needed for their application.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
It takes just as long (if not longer) to learn an XML-based functional language as it does to learn another, plus it's not generally domain-specific. Ever tried writing SOAP manually? The reason the 15 million different compilers/interpreters are running around is because they're elegant solutions to specific problems. XML - as a language, not as a data exchange format - is worse than COBOL, in my opinion, and I hate COBOL.
Thanks Colin
-
It takes just as long (if not longer) to learn an XML-based functional language as it does to learn another, plus it's not generally domain-specific. Ever tried writing SOAP manually? The reason the 15 million different compilers/interpreters are running around is because they're elegant solutions to specific problems. XML - as a language, not as a data exchange format - is worse than COBOL, in my opinion, and I hate COBOL.
Thanks Colin
Colin Meier wrote:
Ever tried writing SOAP manually?
Yes, actually.
Colin Meier wrote:
The reason the 15 million different compilers/interpreters are running around is because they're elegant solutions to specific problems. XML - as a language, not as a data exchange format - is worse than COBOL, in my opinion, and I hate COBOL.
I don't disagree with you completely here, but just something to think about: If we were talking about wheels here, would you really want 15 million different wheels for a given car? While XML solutions are not always the most elegant solution, they do provide a text-readable format that anyone who has read an XML document before can at least follow. That said, XML was not designed as a scripting language; it was designed as a data markup language. The fact that its flexibility allows for such is pretty impressive, but also makes programmers a bit lazy at times.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
I love articles like this[^]. FUD. * I saw the author of Ant at a conference recently and he, quite sadly, noted how his tool had been somewhat perverted. He specifically mentioned how he disagreed with the functionl concepts that had been put into Ant's XML dialect (e.g. conditions.)
regards, Paul Watson Ireland FeedHenry needs you
eh, stop bugging me about it, give it a couple of days, see what happens.
I missed this thread initially. To me, xml can used to represent a tree and every script or compiled language are eventually compiled into some tree structure (lisp is visually more close to a tree before compiling) in order to compute. It's neither easy to write nor elegent as a script (text based) language that's for sure. But if a visual tree manipulation/editing tool can be constructed it will become more "natural" to users and starting there (tree) will actually make it possible to construct very flexible and extensible computational trees (my initial guess is that maybe even lisp can't do it, but I am not a lisp programer) that a single context free language can not generate. If you are interested have a look at [x-script generator](<a href=)[^] which is used to solve this "problem":). It currently generats NAnt xml scripts, which serves as an entrance to any type of NAnt extension languages (or sub-trees), usually domain specific, like build scripts, code generators, etc.. It can also be constructed to interpret any entrance language as well. Although probably no theoretical studis on it exists for the time been (I know it's not in the text book, no flame please), it is practically very useful for many of our build, maintance, and code generation tasks. Once the (sub)language interpretor is written (not a hard task for simple sub-languages), it's rediculously easy to generator xml scripts, since the editor maintains most of the referential replations (integrity) and data input options ... -- modified at 11:37 Thursday 21st September, 2006
-
I love articles like this[^]. FUD. * I saw the author of Ant at a conference recently and he, quite sadly, noted how his tool had been somewhat perverted. He specifically mentioned how he disagreed with the functionl concepts that had been put into Ant's XML dialect (e.g. conditions.)
regards, Paul Watson Ireland FeedHenry needs you
eh, stop bugging me about it, give it a couple of days, see what happens.
Why not make a compiler that will compile the source to an XML language instead of writing the XML? Its kind of like writing in assembly. Also I dont beleive I should know how to build a compiler to be a programmer. He just wants us to buy his book:|
static int Sqrt(int x) { if (x<0) throw new ArgumentOutOfRangeException(); int temp, y=0, b=0x8000, bshft=15, v=x; do { if (v>=(temp=(y<<1)+b<>=1)>0); return y; :omg: