Lua seemed to make simple things complicated, and the misuse of tables for both arrays and objects made things harder than they should have been. It was really awkward to work with. From our perspective, it had a poor debugger, poor I/O, poor architecture, and a poor C API.
From my perspective Lua is the most elegant language I've ever encountered. Brilliant C API, well thought architecture, responsive community... And I hardly need a debugger --- nontrivial code slip from my fingers bugfree.
In fact it's just a matter of philosophy --- you can not write a good code until you accept philosophy of the language you are using.
Thomas Ptacek
· 1 year ago
Speaking in my official capacity on behalf of Matasano Security, LLC, I'd like to point out that it is not Matasano policy to consider LibTomCrypt the gold standard for anything.
Wes Brown
· 1 year ago
@Vyacheslav: Noted, thank you for the correction. It had been a long time since I'd touched LuaSocket. On a certain level, I agree with you about Lua. The problem is that Lua's philosophy is to be as vanilla as possible. It is a very nice language if you need to plug control logic into something greater.
But we had very different goals, and that was to make a small thing rather than a big thing. And we found that Lua's philiosophy and design goals worked against us in that regards.
@Thomas Ptacek: Indeed, indeed! It was the opinion of Ephemeral Security, not of Matasano Security, LLC. Thanks for clarifying this.
Vyacheslav Egorov
· 1 year ago
@Wes: Lua is indeed suitable for development of standalone applications. But yes, sometimes I think that Lua definitely lacks some libraries and features, so I have to create my own bindings, dive deep into internals of old rotten ones and write some metalua macroses...
Roberto Ierusalimschy wrote in PiL "Lua gives you the power; you build the mechanisms.". It's painful to reinvent the wheel, but in the same time it makes certain things simpler. And once you have one, you never need to rebuild it again.
"Ideal Language for All Programmers and All Tasks". There is no such thing. So if certain language is not suitable for your task, just do not use it. No one enforces you... And if you persist: never complain. It was your choice, and your fault. Not the fault of the language. That is how I do things.
// No offense. Sorry, if it looks like one...
drrr
· 1 year ago
Is Mosquito Lisp still being developed? If so, where can we find current code.
Wes Brown
· 1 year ago
@Vyacheslav: That's exactly my point. There is no perfect language for every task, and Lua turned out to be the wrong language for what we wanted to use it for. We were attracted to its relative maturity and its size. But other aspects made it quite unsuitable. It was indeed our choice to pick Lua.
If you note, we did not use Lua next time -- we reinvented the wheel with Mosquito Lisp using what we learned. No offense was taken.
@drrr: Sort of. Mosquito Lisp as a security-specific language isn't being developed anymore. But its descendant, intended to be more general purpose, lives on as WaspVM. Mosquito Lisp was designed for a particular goal and it didn't quite meet what I expected.
If you want a network-oriented streaming Lisp1 that's small, and portable across multiple architectures, check out WaspVM at http://waspvm.blogspot.com/. Please note that I am not in any way involved with this project, nor is Matasano.
I'm currently working on another project along the vein of injectable virtual machines, and I'll reveal it when I think it is ready.
brl
· 1 year ago
Is Matasano working on an injectable virtual machine project? If so, which VM will you use?
Wes Brown
· 1 year ago
@brl: It's one of my projects, yes. And I hate being mysterious, but I don't want to reveal what's behind the curtain without having something more concrete.
brl
· 1 year ago
It's one of our projects too. We ended up choosing the Java VM after a false start with Ruby.
Charlie Cleveland
· 1 year ago
There is a pretty solid graphical Lua debugger available here (just like MSVC):
@wes: can you elaborate on which expectations weren't met by MosquitoLisp? It seemed like that you took it to a quite advanced stage. Why did you abandon it?
Wes Brown
· 1 year ago
@brl: It's been my observation that is hard to reduce an off-the-shelf VM to the size that is needed to be really usable.
@rikitan: I'll be elaborating on this in a future blog post. But in a nutshell, it achived its goals admirably. It is just that at the end of the project, I realized that the goal it achieved did not serve the purpose that I had in mind as well as it could have.
In other words, it was small, it was targeted towards 64K-128K in size, and it had an amazing amount of versatility and functionality for that size, but it wasn't small enough. :)
sdlkfjsldjkf
· 1 year ago
Mr. Ptacek, I'm glad you posted that correction.
Matasano's blog is informative and overall good, but the following statement:
"We settled on LibTomCrypt as our cryptography library, as we considered it the gold standard for such software."
is one of the most ridiculous statements I have ever read on this blog. The author of LibTomCrypt is a complete idiot and I can authoritatively say that guy does not know jack shit about cryptography.
Wes Brown
· 1 year ago
I have edited the post to reflect clearly on Matasano's position. Developing Mosquito was a learning process, and LibTomCrypt looked appealing from the perspective of a programmer trying to minimize the impact of the cryptographic library on the VM in terms of size. LibTomCrypt did offer a nice catalog-esque functionality in which we were able to link in only the specific ciphersystem that we needed.
Needless to say, I have been educated as to LibTomCrypt's inadequacies since then.
Scott W. Dunlop
· 1 year ago
Meh. The object code was small, the code was readable, the documentation was sufficient and it was written in C. The rest was negotiable for me, and I make no apologies for using it. :)
All Comments
From my perspective Lua is the most elegant language I've ever encountered. Brilliant C API, well thought architecture, responsive community... And I hardly need a debugger --- nontrivial code slip from my fingers bugfree.
In fact it's just a matter of philosophy --- you can not write a good code until you accept philosophy of the language you are using.
But we had very different goals, and that was to make a small thing rather than a big thing. And we found that Lua's philiosophy and design goals worked against us in that regards.
@Thomas Ptacek: Indeed, indeed! It was the opinion of Ephemeral Security, not of Matasano Security, LLC. Thanks for clarifying this.
Roberto Ierusalimschy wrote in PiL "Lua gives you the power; you build the mechanisms.". It's painful to reinvent the wheel, but in the same time it makes certain things simpler. And once you have one, you never need to rebuild it again.
"Ideal Language for All Programmers and All Tasks". There is no such thing. So if certain language is not suitable for your task, just do not use it. No one enforces you... And if you persist: never complain. It was your choice, and your fault. Not the fault of the language. That is how I do things.
// No offense. Sorry, if it looks like one...
If you note, we did not use Lua next time -- we reinvented the wheel with Mosquito Lisp using what we learned. No offense was taken.
@drrr: Sort of. Mosquito Lisp as a security-specific language isn't being developed anymore. But its descendant, intended to be more general purpose, lives on as WaspVM. Mosquito Lisp was designed for a particular goal and it didn't quite meet what I expected.
If you want a network-oriented streaming Lisp1 that's small, and portable across multiple architectures, check out WaspVM at http://waspvm.blogspot.com/. Please note that I am not in any way involved with this project, nor is Matasano.
I'm currently working on another project along the vein of injectable virtual machines, and I'll reveal it when I think it is ready.
http://www.unknownworlds.com/decoda
@rikitan: I'll be elaborating on this in a future blog post. But in a nutshell, it achived its goals admirably. It is just that at the end of the project, I realized that the goal it achieved did not serve the purpose that I had in mind as well as it could have.
In other words, it was small, it was targeted towards 64K-128K in size, and it had an amazing amount of versatility and functionality for that size, but it wasn't small enough. :)
Matasano's blog is informative and overall good, but the following statement:
"We settled on LibTomCrypt as our cryptography library, as we considered it the gold standard for such software."
is one of the most ridiculous statements I have ever read on this blog. The author of LibTomCrypt is a complete idiot and I can authoritatively say that guy does not know jack shit about cryptography.
Needless to say, I have been educated as to LibTomCrypt's inadequacies since then.