Re: Why is Elisp slow?

[Tadeus Prastowo]

On Mon, May 6, 2019 at 11:03 AM 조성빈 <pcr910303@icloud.com> wrote:
>
> 2019. 5. 6. 오후 4:33, Tadeus Prastowo <tadeus.prastowo@unitn.it> 작성:
>
> > On Sun, May 5, 2019 at 5:51 PM Stefan Monnier
> > <monnier@iro.umontreal.ca> wrote:> Language interoperation is very
> > difficult, and even more so if you want
> >> both languages to be usable "equally" (as opposed to a high-level
> >> language with FFI bindings, say).  The .NET platform aims to do just
> >> that, and note that it's fairly complex and the most successful
> >> languages there were specifically designed/tweaked for that platform.
> >
> > Out of curiosity, do you mind to elaborate on how it is to be usable
> > "equally"?  (I think the best way to understand it is by studying the
> > .NET platform, but maybe you could explain it better).
>
> I would say as ‘to do something in a way that is considered idiomatic in the 
> language’.
> For example, some APIs (in general) makes sense when they use C++ templates 
> or Rust `impl` blocks; it doesn’t make sense to enforce type unsafety.
> Some APIs makes sense when they are provided as Lisp macros or babel macros; 
> it doesn’t make sense to enforce boilerplate code.
>
> Have you ever done FFI between two high level languages, e.g. Swift and Rust? 
> It’s a real pain, because the interfacing code can’t use any of the language 
> features as they should be defined by their common dominators: the SysV ABI.
> You can’t use generics, tuples, lambdas, etc... even though both languages 
> have them.
>
> It’s well, a somewhat similar experience.

Okay, I got it now.  In that case, the difficulty of using both
languages "equally" is a natural problem that is found also in, for
example, the English vs. Chinese vs. other natural language vocabulary
mismatches.

Thank you very much for taking the time to explain the things through.

-- 
Best regards,
Tadeus