From: Tamas K Papp on
On Tue, 16 Mar 2010 05:11:45 -0700, Mark Carter wrote:

> I'm not really a Lisp programmer, but I saw an ad for Bee Lisp. Anyone
> heard of it? Is it any good?

I am curious where you saw the ad. Based on first impressions, Bee
Lisp is either a scam or a misguided attempt. In either case, it seems
surprising that they advertise.

Tamas
From: Futu Ranon on
On Tue, 16 Mar 2010 09:51:48 -0400, Tamas K Papp <tkpapp(a)gmail.com> wrote:

> On Tue, 16 Mar 2010 05:11:45 -0700, Mark Carter wrote:
>
>> I'm not really a Lisp programmer, but I saw an ad for Bee Lisp. Anyone
>> heard of it? Is it any good?
>
> I am curious where you saw the ad. Based on first impressions, Bee
> Lisp is either a scam or a misguided attempt. In either case, it seems
> surprising that they advertise.
>
> Tamas

I've seen it in (and first heard of it from) gmail targeted ads and on
Google searches.
From: refun on
In article <op.u9nvz7zfiht87w(a)colorado.weissasset.local>, futuranon(a)gmail.com
says...

I've once bumped into it before as I saw it linked from Wikipedia's Lisp page,
but apparently they've removed it as it was spam:
http://en.wikipedia.org/w/index.php?title=Lisp_%28programming_language%29
&action=historysubmit&diff=339709588&oldid=338728703

The code samples appeared weird in their indentation and syntax. The function
names were close to CL's in some places, but the semantics were rather
different (DEFMACRO seems to be a way to define a function which will be
inlined, you can find the documentation in the CHM file included with the
demo). The standard library is rather tiny and the functions seem rather low-
level(malloc/free, JMP/CMP/CJMPREL/JMPREL/CALL/CALLAPI and some others).

This claim
> I did enjoy this claim from the website:
>
> > BEE Lisp Compiler and the Lisp language itself makes compiled programs
> > very difficult to crack or to reverse engineer.

made me curious, so I did take a second look at it.
A 15minute glance at the demo executable told me the following things:
- It's coded in C++, with heavy non-portable Win32 extensions, compiled with
Microsoft's C compiler version 8 (included in Visual Studio).
- The claim about it being a compiler is misleading - it's not a native code
compiler, but a bytecode one. Actually all code is compiled into bytecode and
appended at the end of the executable or DLL. They also seem to encrypt all the
strings with a simple 8bit/1byte xor cipher with a constant key for the entire
file(the fact that they use strings for almost everything was something that I
found strange). The interpreter reads the bytecode from the executable using
file APIs, which I'd expect to be quite slow, and it does it on-demand (one
instruction at a time).
- All standard/documented forms seem to be special forms which are handled in
the interpreter.
- There is more than enough info in the executable to make it rather easy for
an industrious reverse engineer to make a decompiler if they wanted. I think
reverse engineering code compiled for example by SBCL, despite being open
source, is a lot more harder than this.
I also don't think they stole GPL code unlike fortunatus' guess. Most of the
code is Windows API specific and the language seems a lot more primitive than
LISP 1.5 was. Anyone seriously considering writing real code should probably
pick a real Lisp instead, however I suppose it has some merit for giving
comfort to those that think picking an obscure/unused language with a strange
implementation which intentionally (slightly) obfuscates the generated code
will protect them from someone reverse engineering their precious secrets.
From: Futu Ranon on
On Tue, 16 Mar 2010 10:49:33 -0400, refun <refun(a)nospam.gmx.com> wrote:

> The code samples appeared weird in their indentation and syntax. The
> function
> names were close to CL's in some places, but the semantics were rather
> different (DEFMACRO seems to be a way to define a function which will be
> inlined, you can find the documentation in the CHM file included with the
> demo). The standard library is rather tiny and the functions seem
> rather low-
> level(malloc/free, JMP/CMP/CJMPREL/JMPREL/CALL/CALLAPI and some others).

Online docs are here:
http://www.beelisp.com/online-help/default.htm

DEFMACRO:
http://www.beelisp.com/online-help/default.htm?turl=WordDocuments%2F_list__defmacro_name_parameters_body.htm

> <list> DEFMACRO (name parameters body)
> Defines marco and returns its body. Unlike function, macro body is
> inserted in place of its call.
> Example:
> (DEFMACRO println (text)
> (PRINT text)
> (PRINT “\n”)
> )

Who is Marco and what is BEE Lisp doing with his body?
From: Andrew Poelstra on
On 2010-03-16, Futu Ranon <futuranon(a)gmail.com> wrote:
> On Tue, 16 Mar 2010 10:49:33 -0400, refun <refun(a)nospam.gmx.com> wrote:
>
>> The code samples appeared weird in their indentation and syntax. The
>> function
>> names were close to CL's in some places, but the semantics were rather
>> different (DEFMACRO seems to be a way to define a function which will be
>> inlined, you can find the documentation in the CHM file included with the
>> demo). The standard library is rather tiny and the functions seem
>> rather low-
>> level(malloc/free, JMP/CMP/CJMPREL/JMPREL/CALL/CALLAPI and some others).
>
> Online docs are here:
> http://www.beelisp.com/online-help/default.htm
>
> DEFMACRO:
> http://www.beelisp.com/online-help/default.htm?turl=WordDocuments%2F_list__defmacro_name_parameters_body.htm
>
>> <list> DEFMACRO (name parameters body)
>> Defines marco and returns its body. Unlike function, macro body is
>> inserted in place of its call.
>> Example:
>> (DEFMACRO println (text)
>> (PRINT text)
>> (PRINT “\n”)
>> )
>
> Who is Marco and what is BEE Lisp doing with his body?

It's obvious they made a typo and intended to write "defiles".

--
Andrew Poelstra
http://www.wpsoftware.net/andrew
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: A pascal generator in CL ?
Next: lightweight database