[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: parsing markup with Perl
On Mon, Feb 10, 2014 at 10:47 AM, Shlomi Fish <shlomif@shlomifish.org> wrote: > Hi Ihe, > Hello Again, > > I guess I agree that it's a false dichotomy, but please don't attribute it to > Mr. Poe, because I was quoting and possibly paraphrasing on what he said from > memory. In any case, the Freecell Solver core source code alone > ( http://fc-solve.shlomifish.org/ - my own project ) now contains source code > and markup in C, Perl 5, GNU make, Python, Ruby, CMake, AsciiDoc, Bash, and > possibly other languages and I noticed that some other open source projects also > contain quite a bit of mishmash of stuff (don't know how the situation is with > proprietary software). So while not a dichotomy, the situation is still > certainly possible and may badly affect the accessibility and approachability > of contributing for the project. > Well thats a different kettle of fish because there you have people contributing in multiple general purpose languages so I can agree with you there. >> >> Domain specific language vs Domain specific language masquerading as a >> possibly non-(standard|compatible|interoperable|performant|optimized) >> domain specific library in a general purpose language. >> >> Choose as your poison the one that is less likely to make you sick/die. >> > > Not sure I understand, but I think you mean something like that if working in > PHP or Perl (for example) you should not parse HTML and XML directly by using > one-off regular expressions, but rather use a normal and sane parser. (To give > an example for what you mean and not keep it abstract). I can 100% agree with > it, but it is may be sometimes better to reinvent small wheels (in a good way) > than to drag an entire framework (or even module or library) for that. > It depends on the domain of the project subject matter. For example at what point does the amount of math you are doing mean you should be using R/Matlab/Mathematica or Octave. Perhaps if you are a Python Developer and/or know/believe in numpy/scipy the answer may well be never. > Moreover, sometimes writing "ugly"/complicated/inelegant code with some > so-called anti-patterns can go a long way in making sure your code is kept > simple (see https://en.wikipedia.org/wiki/KISS_principle ). This is instead of > using an abstraction that tries to produce the most elegant code any time, and > ends up being hard to learn, use and read (there's some previous discussion on > it in this thread of Sayeret Lambda (an Israeli group of programming languages' > enthusiasts) > People who code in Python but can't grok List Comprehensions use the exact same argument. >> > >> > Perfect is often the >> > enemy of good. >> > >> >> Very true but often used as an excuse to unnecessarily implement crap. >> > > That's right. Someone I know used to have "Good is the enemy of great." as his > signature. It shouldn't be taken as gospel, and quotes (like the Rules of > Acquisition) can only be considered as guidelines, and I have my share of two > apparently conflicting quotes, and quotes that I know which are amusing, but > that I can no longer agree with (including ironically some quotes of my own.). > > I also read somewhere that many "famous" quotes and aphorisms are used to feign > authority, and so should be avoided as much as possible. > Well I don't think I introduced any in our conversation :). But a more economical way of expressing the DSL vs DSL masquerading as library point would have been to state Greenspun's Tenth Rule ( applied to the DSL being aped rather than Lisp).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|