love5an: (R)

public static void CallWithEscapeContinuation(Action<Action> f)
{
  var escapeTag = new Exception();
  Action escapeProcedure = () => { throw escapeTag; };
  try
  {
    f(escapeProcedure);
  }
  catch (Exception e)
  {
    if (ReferenceEquals(escapeTag, e)) return;
    throw;
  }
}

love5an: (Default)
Скрепя сердце, с сожалением и горечью, но тем не менее, движимый рациональным подходом к делу, перевел код программы для своего стартапа с Common Lisp на Microsoft .NET, а именно на C#.

Причины довольно банальны и прозаичны.

Первые две, в принципе, связаны, и хотя одну из них можно было бы компенсировать другой, у CL проблемы с обеими:


  1. Недостаток инфраструктуры. Ни для кого ни секрет, что у CL довольно неслабые проблемы с библиотеками, начиная со стандартной, и особенно с библиотеками под Windows. В принципе, это всё дело решаемое, и я бы мог для своего проекта написать всё сам, но, тем не менее, прикинув в голове, сколько бы это заняло усилий, и сколько бы родилось велосипедов, я от этого отказался. У .NET с другой стороны, инфраструктура даже стандартной библиотеки(BCL) просто огромна, и покрывает не только минимум вроде, например, I/O или работы с кодировками, но и более сложные и абстрактные вещи(см. пункт 4), и я уже не говорю про платформы для графического интерфейса(WPF, WinForms). В принципе, не будь второй проблемы, эта конкретная была бы не помехой. А вторая проблема такая:

  2. Недостаток специалистов со знанием CL. Проблема тоже довольно известная, и, к сожалению, стоящая очень остро. В моем случае - из всех подключенных к делу людей, с Common Lisp до такого уровня, чтобы писать на нем "production quality" код, знаком только я. Будь специалистов больше, как я уже сказал, проблема с инфраструктурой не стояла бы так остро.

  3. Порт SBCL под Windows, похоже, заброшен. Последний коммит был 4 месяца назад :( https://github.com/akovalenko/sbcl-win32-threads

  4. Linq Expression Trees. В .NET 3.5 Microsoft ввели такую сумасшедшую штуку, которая рядовыми программистами практически не используется, но которая очень полезна и необходима таким заклиненным на всяких лиспах людям, как я. Linq Expression Trees это инструмент для кодогенерации в рантайме. Они позволяют составлять AST(абстрактное синтаксическое дерево) из "выражений", компилировать его и запускать. Фича эта для моего проекта крайне необходимая, так как один из основных компонентов программы - генератор и компилятор packrat-парсеров из PEG.
    Вот небольшой пример, для сравнения с CL:

    (let* ((code `(lambda (x y) (+ x y)))
           (f (compile nil code)))
      (print (funcall f 1 2)))
    
    ;; ==> 3
    


    На C#, с использованием Linq Expression Trees будет так:

    using System;
    using System.Linq.Expressions;
    
    class Program
    {
      static void Main()
      {
        var xParam = Expression.Parameter(typeof(int), "x");
        var yParam = Expression.Parameter(typeof(int), "y");
        var body = Expression.Add(xParam, yParam);
        var code = Expression.Lambda(body ,xParam, yParam);
        var f = code.Compile();
        Console.WriteLine(f.DynamicInvoke(1, 2));
        // ==> 3
      }
    }
    

  5. C# довольно неплохой язык, хоть и не CL. В частности, в C# 4.0(а это теперь основной инструмент разработки) существует множество интересных фич, которые приближают его к таким мощным инструментам, как мой любимый Common Lisp. Здесь я имею ввиду возможности самого языка - начиная с анонимных делегатов и лямбд и заканчивая "dynamic", который фактически вводит в C# простенький аналог мультиметодов CLOS. Кстати, у кого-нибудь, возможно, может возникнуть вопрос "почему не на Java и JVM?" - так вот в том числе и поэтому. .NET и C# объективно удобнее и мощнее JVM и Java.


Такая "смена рельс" тем не менее не означает отсутствие в программе встроенного лиспа, о котором я писал ранее. Я планирую реализовать его сначала как интерпретатор, а потом, смотря по ситуации и по материальным, моральным и т.п. ресурсам, возможно и как компилятор в MSIL, а потом возможно и как компилятор в native-код.
love5an: (Default)
И потом переведен в C++ автоматическим source-to-source транслятором.
http://channel9.msdn.com/Shows/Going+Deep/Patrick-Dussud-Garbage-Collection-Past-Present-and-Future

Его разработчик, Patrick Dussud, являвшийся главным инженером по части GC в .NET(и являющийся теперь, как MS пишет - lead architect for the .NET Common Language Runtime, the chief architect for the .NET Framework, and is a member of the Window Core Architecture team) - раньше работал в Texas Instruments и других подобных компаниях(например Lucid Inc.) и писал там в частности на ZetaLisp(диалект для Lisp-машин, предшественник Common Lisp) и на собственно самом Common Lisp.
http://www.microsoft.com/presspass/exec/techfellow/dussud/default.mspx

Такие вот дела.
Крайне интересный факт, по-моему.
love5an: (Default)
Надо признать, я солидарен с вот этим постингом в том, какая проблема у лиспа(и у Common Lisp в частности) на текущий момент является ключевой, и какая отталкивает от него разработчиков.
http://my-clojure.blogspot.com/2011/07/lisp.html

Проблема эта - библиотеки.
Это одновременно и хорошо, и плохо. Хорошо потому, что другим проблем, в принципе, нет, а эта - решаема, а плохо потому, что все таки проблема стоит довольно остро, и решить ее довольно сложно, и более того, она порождает своеобразный замкнутый круг - на лиспе не пишут потому, что мало библиотек, а мало библиотек потому, что никто их особо не пишет.

Read more... )
love5an: (Default)
А вот какой должна быть архитектура ОС ближайшего будущего?

Понятное дело, что все то говно, которое мы имеем сейчас, от AIX до Windows линейки NT - безнадежно устарело.
Read more... )

Profile

love5an: (Default)
Dmitry Ignatiev

December 2016

S M T W T F S
    123
45678910
11121314 151617
18192021222324
25262728293031

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 23rd, 2017 03:52 am
Powered by Dreamwidth Studios