Hacker News Reader

Comment by WalterBright | Hacker News Reader

Using third party lexer generators means your project is now dependent on that tool. This means:

1. the tool must exist on every platform your project will ever be ported to

2. the same version of that tool must exist on every such platform

3. if the hosted compiler changes, the tool must be updated in sync with that compiler - out of sync means your project won't build

4. if there are blocker bugs in the tool, you're not in a good position to fix it. You're stuck with developing workarounds.

5. Everyone building your project has to get the tool successfully installed.

The current build of D's runtime library has a dependency on libcurl. Supposedly, since libcurl is ubiquitous, that shouldn't be any problem. But it has been an ongoing sore relentlessly sucking up multiple peoples' time, of the issues I outlined above.

View on HN

#1. What platforms do you think people would actually want to run a static analyzer on?

#2. You can enforce dependencies at a project level if you cared to. Lexers really haven't changed much from version to version.

Based on #3, you don't understand how lexers work.

Also, based on #4, do you actually know anybody that has encountered a blocking bug with a lexer?

#5. WHAT? How is that even remotely hard. This is a static analyzer. I'm not using my arduino to analyze code or anything.

> Using third party lexer generators means your project is now dependent on that tool.

I would submit that porting D is signficantly harder than porting flex and/or ragel. Not to mention that the number of platforms that support C++ and D but not flex should be smaller than the number of platforms that support C++ and flex but not D?

It's easier to just write the lexer by hand than deal with those issues.

Your arguments seem to equally apply to using third-party libraries at all. Are you suggesting that it's better to (for example) re-implement HTTP rather than use libcurl?

I'm saying you've got to have pretty strong arguments to make a project dependent on a third party tool, if you expect to distribute it, expect it to be long lived, and expect to port it to many platforms.

Yes I agree with the point that the portability of your dependencies limits your own portability.

This is definitely something that is dependent on the tool or library though. For example, if you decided to use Lua as a tool, it is extremely unlikely that the portability of Lua will be a limiting factor. It is very likely to be more portable than your code (given that it compiles unmodified on Turbo C 1.0 from 1990: http://www.youtube.com/watch?v=-jvLY5pUwic)

So I definitely agree with "choose your dependencies wisely."

...and if you decided to use Lua, you could also use LPEG, which is amazingly well suited to tasks like this...

[LPEG is also a dependency of course, but pretty small (just include its source code along with your own) and super portable in the same way Lua is.]

Reply on news.ycombinator.com