Доброго дня!

После более-менее плотного знакомства со Scala пару лет назад, я не решился использовать ее. Так как мне этот язык показался несколько переусложненным, слишком динамично меняющимся и недостаточно качественно реализованным. Но время идет, ситуация, возможно, меняется. Сейчас Twitter использует Scala. Состоялся релиз web-фреймворка Lift. В блогах ScalaActors зачастую упоминаются в купе с Erlang-ом как образец использования модели актеров...

Так вот интересно, рассматривает ли уже кто-нибудь Scala как пригодный для промышленного программирования? Использует ли? Или планирует использовать? Категорически не собирается использовать?

Буду признателен за любые соображения на эту тему.

eao197 пишет:

> решился использовать ее. Так как мне этот язык показался несколько
> переусложненным, слишком динамично меняющимся и недостаточно качественно

SCALA переусложнённая ? Ну, извини ...
SCALA — это МОЩЬ !

> Так вот интересно, рассматривает ли уже кто-нибудь Scala как пригодный
> для промышленного программирования? Использует ли? Или планирует
> использовать? Категорически не собирается использовать?

Ну я не вижу, почему бы её не использовать.
Она генерирует точно такой же p-code, как и Java , вроде бы.
Ну, может конечно неоптимально генерировать. Но далее вроде
бы уже на уровне p-code-а Java-машина докомпилировывает
и оптимизирует.

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

Я, конечно, пока не большой знаток, пока ещё не использовал,
но хочу что-то вместо Java. Либо scala, либо Jithon, либо CLOJURE.

Здравствуйте, MasterZiv, Вы писали:


.
MZ>Она генерирует точно такой же p-code, как и Java , вроде бы.

Java не генерирует p-код. И это мало говорит о достоинствах
языка.

Насчёт Scala: не использую и не буду, т.к. не люблю всё маргинальное и ненормальное.
А кто верит шумихе — пусть посмотрит, что именно запрограммировано на Scala и стоит ли оно
того, чтобы шуметь.

Ещё и название Scala глупое.

Здравствуйте, MasterZiv, Вы писали:

>> решился использовать ее. Так как мне этот язык показался несколько
>> переусложненным, слишком динамично меняющимся и недостаточно качественно

MZ>SCALA переусложнённая ? Ну, извини ...
MZ>SCALA — это МОЩЬ !

Меня постоянно вводили в ступор такие вещи, как контравариантность и ко/контравариантные позиции аргументов.

MZ>Я, конечно, пока не большой знаток, пока ещё не использовал,
MZ>но хочу что-то вместо Java. Либо scala, либо Jithon, либо CLOJURE.

Это напоминает перефразированное "Булгакова не читал..." -- не читал, но при случае прочитаю обязательно

Если серьезно, то Scala и Jython -- все-таки языки для разных задач. И если Scala как замена Java еще понятно, то вот Jython как замена Java... Ну разве что в области задач, в которых рулят скриптовые языки.

Собственно, вопрос упирается в то, считает ли кто-нибудь Scala достаточно стабильным языком, для того, чтобы тратить ресурсы на создание кодовой базы на Scala. Т.е. во главу угла ставится не столько мощность языка, сколько его собственная стабильность и наличие вокруг него достаточно развитой инфраструктуры (в виде коммунити, базы пользователей, инструментов и документации).

Здравствуйте, eao197, Вы писали:

E>Так вот интересно, рассматривает ли уже кто-нибудь Scala как пригодный для промышленного программирования? Использует ли? Или планирует использовать? Категорически не собирается использовать?

Я не использовал Скалу промышленно — года полтора назад написал на ней компилятор ~3K строк — думаю версия тогда была 2.4. С тех пор пересобираю его под каждой новой версией — проблем не было.

Типоголизм я особенно не трогал — мне нужен был язык типа SML (дататипы, паттерн-матчинг, немного RAII и интероп с Java) — все это я в принципе получил, хотя из-за аннотаций типов порой трудно уместиться в 80 колонок.

Если мне придется еще что-нибуть писать под JVM — разумеется выберу Скалу, а под Net: F#

Сам Одерски некоторое время назад оценивал зрелость компилятора на уровне javac 1.4 (он был одним из разработчиков — если кто не знает).

eao197 пишет:

> Это напоминает перефразированное "Булгакова не читал..." -- не читал, но
> при случае прочитаю обязательно

да читал я, читал. И, кстати, не Булгакова, а Пастернака.

> Если серьезно, то Scala и Jython -- все-таки языки для разных задач. И

Ну, функциональные и объектно-ориентированные языки общего назначения, не
понимаю, почему для разных.

> если Scala как замена Java еще понятно, то вот Jython как замена Java...

То же самое. Лучшая Java.

> Ну разве что в области задач, в которых рулят скриптовые языки.

При чём тут скриптовость ?
Если под ним Java-машина лежит, уже всё, нет скриптовости.

Здравствуйте, MasterZiv, Вы писали:

>> Если серьезно, то Scala и Jython -- все-таки языки для разных задач. И

MZ>Ну, функциональные и объектно-ориентированные языки общего назначения, не
MZ>понимаю, почему для разных.

>> если Scala как замена Java еще понятно, то вот Jython как замена Java...

MZ>То же самое. Лучшая Java.

Если под Jython-ом понимается именно Jython, то это же Python, только поверх Java. По производительности он вряд ли когда-нибудь сравниться со статически-типизированной Scala.

Здравствуйте, MasterZiv, Вы писали:

>> Ну разве что в области задач, в которых рулят скриптовые языки.

MZ>При чём тут скриптовость ?
MZ>Если под ним Java-машина лежит, уже всё, нет скриптовости.

Не повторяй больше эту глупость. Код родным питоном тоже машинные коды лежат, но это не делает его компилируемым.

eao197 пишет:

> <http://www.jython.org/Project/&gt;, то это же Python, только поверх Java.
> По производительности он вряд ли когда-нибудь сравниться со
> статически-типизированной Scala.

Чем там НЕстатическая типизация вам не угодила по производительности?
Ну, есть может там накладуха небольшая, но вы же не дефуры будете
на питоне решать. А там эти +- 2 милисекунды никому не помешают.

VladD2 пишет:

> Не повторяй больше эту глупость. Код родным питоном тоже машинные коды
> лежат, но это не делает его компилируемым.

Я конечно не большой эксперт, но вроде бы как именно в C-Python
код (уже P-код, конечно) интерпретируется. JAVA имеет Jit.
В питоне вроде бы его нет.

А в чём тогда по-твоему разница между компилятором и интерпретатором ?
Расскажи, пожалуйста, потому как штука сложная, где там интерпретатор,
где компилятор --- уже давно нихрена не понятно.

Здравствуйте, MasterZiv, Вы писали:

>> <http://www.jython.org/Project/&gt;, то это же Python, только поверх Java.
>> По производительности он вряд ли когда-нибудь сравниться со
>> статически-типизированной Scala.

MZ>Чем там НЕстатическая типизация вам не угодила по производительности?

В данной теме это уже оффтопик. Предлагаю его не развивать, тем более, что священных войн static vs dynamic на RSDN отгремело уже достаточно.

MZ>Ну, есть может там накладуха небольшая, но вы же не дефуры будете
MZ>на питоне решать. А там эти +- 2 милисекунды никому не помешают.

Не дифуры. На данный момент я занимаюсь нагруженными серверами и, временами, обработкой больших объемов данных. Лишние миллисекунды мешают, иногда очень сильно.

Здравствуйте, MasterZiv, Вы писали:

MZ>А в чём тогда по-твоему разница между компилятором и интерпретатором ?
MZ>Расскажи, пожалуйста, потому как штука сложная, где там интерпретатор,
MZ>где компилятор --- уже давно нихрена не понятно.

Jython (как и IronPython) не полноценный компилятор в ява байткод, это грубо
говоря виртуальная машина для питона написанная на ява вместо си.

Здравствуйте, MasterZiv, Вы писали:

MZ>А в чём тогда по-твоему разница между компилятором и интерпретатором ?
MZ>Расскажи, пожалуйста, потому как штука сложная, где там интерпретатор,
MZ>где компилятор --- уже давно нихрена не понятно.

Ну нет — разница между компилятором и интерпретатором на практике весома, груба и зрима.
Здесь

Автор: Klapaucius
Дата: 09.06.07

представлена демонстрация разницы для IronPython.
Если же мы воспользуемся jythonc версии 2.2.1 для компиляции того же самого примера

# Fibonacci numbers module
def fib(n): # write Fibonacci series up to n
    a, b = 0, 1
    while b < n:
        print b,
        a, b = b, a+b

def fib2(n): # return Fibonacci series up to n
    result = []
    a, b = 0, 1
    while b < n:
        result.append(b)
        a, b = b, a+b
    return result

— получим вот что:

import org.python.core.*;

public class fibo extends java.lang.Object {
    static String[] jpy$mainProperties = new String[] {"python.modules.builtin", "exceptions:org.python.core.exceptions"};
    static String[] jpy$proxyProperties = new String[] {"python.modules.builtin", "exceptions:org.python.core.exceptions", "python.options.showJavaExceptions", "true"};
    static String[] jpy$packages = new String[] {};
    
    public static class _PyInner extends PyFunctionTable implements PyRunnable {
        private static PyObject i$0;
        private static PyObject i$1;
        private static PyObject s$2;
        private static PyFunctionTable funcTable;
        private static PyCode c$0_fib;
        private static PyCode c$1_fib2;
        private static PyCode c$2_main;
        private static void initConstants() {
            i$0 = Py.newInteger(0);
            i$1 = Py.newInteger(1);
            s$2 = Py.newString("C:\\jython2.2.1\\fibo.py");
            funcTable = new _PyInner();
            c$0_fib = Py.newCode(1, new String[] {"n", "b", "a"}, "C:\\jython2.2.1\\fibo.py", "fib", false, false, funcTable, 0, null, null, 0, 17);
            c$1_fib2 = Py.newCode(1, new String[] {"n", "b", "result", "a"}, "C:\\jython2.2.1\\fibo.py", "fib2", false, false, funcTable, 1, null, null, 0, 17);
            c$2_main = Py.newCode(0, new String[] {}, "C:\\jython2.2.1\\fibo.py", "main", false, false, funcTable, 2, null, null, 0, 16);
        }
        
        
        public PyCode getMain() {
            if (c$2_main == null) _PyInner.initConstants();
            return c$2_main;
        }
        
        public PyObject call_function(int index, PyFrame frame) {
            switch (index){
                case 0:
                return _PyInner.fib$1(frame);
                case 1:
                return _PyInner.fib2$2(frame);
                case 2:
                return _PyInner.main$3(frame);
                default:
                return null;
            }
        }
        
        private static PyObject fib$1(PyFrame frame) {
            // Temporary Variables
            PyObject[] t$0$PyObject__;
            
            // Code
            t$0$PyObject__ = org.python.core.Py.unpackSequence(new PyTuple(new PyObject[] {i$0, i$1}), 2);
            frame.setlocal(2, t$0$PyObject__[0]);
            frame.setlocal(1, t$0$PyObject__[1]);
            while (frame.getlocal(1)._lt(frame.getlocal(0)).__nonzero__()) {
                Py.printComma(Py.None, frame.getlocal(1));
                t$0$PyObject__ = org.python.core.Py.unpackSequence(new PyTuple(new PyObject[] {frame.getlocal(1), frame.getlocal(2)._add(frame.getlocal(1))}), 2);
                frame.setlocal(2, t$0$PyObject__[0]);
                frame.setlocal(1, t$0$PyObject__[1]);
            }
            return Py.None;
        }
        
        private static PyObject fib2$2(PyFrame frame) {
            // Temporary Variables
            PyObject[] t$0$PyObject__;
            
            // Code
            frame.setlocal(2, new PyList(new PyObject[] {}));
            t$0$PyObject__ = org.python.core.Py.unpackSequence(new PyTuple(new PyObject[] {i$0, i$1}), 2);
            frame.setlocal(3, t$0$PyObject__[0]);
            frame.setlocal(1, t$0$PyObject__[1]);
            while (frame.getlocal(1)._lt(frame.getlocal(0)).__nonzero__()) {
                frame.getlocal(2).invoke("append", frame.getlocal(1));
                t$0$PyObject__ = org.python.core.Py.unpackSequence(new PyTuple(new PyObject[] {frame.getlocal(1), frame.getlocal(3)._add(frame.getlocal(1))}), 2);
                frame.setlocal(3, t$0$PyObject__[0]);
                frame.setlocal(1, t$0$PyObject__[1]);
            }
            return frame.getlocal(2);
        }
        
        private static PyObject main$3(PyFrame frame) {
            frame.setglobal("__file__", s$2);
            
            frame.setlocal("fib", new PyFunction(frame.f_globals, new PyObject[] {}, c$0_fib));
            frame.setlocal("fib2", new PyFunction(frame.f_globals, new PyObject[] {}, c$1_fib2));
            return Py.None;
        }
        
    }
    public static void moduleDictInit(PyObject dict) {
        dict.__setitem__("__name__", new PyString("fibo"));
        Py.runCode(new _PyInner().getMain(), dict, dict);
    }
    
    public static void main(String[] args) throws java.lang.Exception {
        String[] newargs = new String[args.length+1];
        newargs[0] = "fibo";
        java.lang.System.arraycopy(args, 0, newargs, 1, args.length);
        Py.runMain(fibo._PyInner.class, newargs, fibo.jpy$packages, fibo.jpy$mainProperties, "", new String[] {"fibo"});
    }
}

С добавлением Dynamic Language Runtime в .NET 4.0 ситуация для IronPython'а должна улучшиться.

Здравствуйте, MasterZiv, Вы писали:

MZ>VladD2 пишет:

>> Не повторяй больше эту глупость. Код родным питоном тоже машинные коды
>> лежат, но это не делает его компилируемым.

MZ>Я конечно не большой эксперт, но вроде бы как именно в C-Python
MZ>код (уже P-код, конечно) интерпретируется. JAVA имеет Jit.
MZ>В питоне вроде бы его нет.

MZ>А в чём тогда по-твоему разница между компилятором и интерпретатором ?
MZ>Расскажи, пожалуйста, потому как штука сложная, где там интерпретатор,
MZ>где компилятор --- уже давно нихрена не понятно.

Раз в вирт. машине отсутствует поддержка динамических языков, то как вообще можно скомпилировать pyhton-код в байт-код?

obj.foo() — во что это будет компилироватья?

Может и можно, только это будет уже все что угодно, но не динамически типизированный Puthon в сегдняшнем виде.

Здравствуйте, Qbit86, Вы писали:

Q>С добавлением Dynamic Language Runtime в .NET 4.0 ситуация для IronPython'а должна улучшиться.

в java 7 аналогичную хрень обещают

Здравствуйте, LaPerouse, Вы писали:


LP>obj.foo() — во что это будет компилироватья?

LP>Может и можно, только это будет уже все что угодно, но не динамически типизированный Puthon в сегдняшнем виде.

Компилировать динамический язык вполне реально, тот же PyPy http://codespeak.net/pypy/dist/pypy/doc/ умудряется большую часть среднетипичного кода трансформировать в статитически типизированный RPython.
Да и явовские JIT'ы ведут свою родословную от JIT динамически типизированного Smalltalk'а.

Здравствуйте, Qbit86, Вы писали:

Q>С добавлением Dynamic Language Runtime в .NET 4.0 ситуация для IronPython'а должна улучшиться.

DLR, собственно, в IronPython и появился. Они просто его оттуда вычленят и сделают более доступным для других в виде части фреймворка. Сам IronPython от этого никак не изменится.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, LaPerouse, Вы писали:


LP>>obj.foo() — во что это будет компилироватья?

LP>>Может и можно, только это будет уже все что угодно, но не динамически типизированный Puthon в сегдняшнем виде.

FR>Компилировать динамический язык вполне реально, тот же PyPy http://codespeak.net/pypy/dist/pypy/doc/ умудряется большую часть среднетипичного кода трансформировать в статитически типизированный RPython.
FR>Да и явовские JIT'ы ведут свою родословную от JIT динамически типизированного Smalltalk'а.

Мне околопитоновское окружение абсолютно неизвестно, я просто исхожу из общих рассуждений о невозможности скомпилировать динамический язык в статический байт-код. Причина очевидна — нет информации о типе и взять ее неоткуда, разве что не прогнать программу в интерпретаторе и посмотреть в рантаймовые типы, делая стат. связки если можно и транслировать в сообщение об ошибке компиляции NoSuchMethodException когда нельзя. Чудес не бывает.

Здравствуйте, z00n, Вы писали:

Z>Здравствуйте, eao197, Вы писали:

E>>Так вот интересно, рассматривает ли уже кто-нибудь Scala как пригодный для промышленного программирования? Использует ли? Или планирует использовать? Категорически не собирается использовать?

Z>Я не использовал Скалу промышленно — года полтора назад написал на ней компилятор ~3K строк — думаю версия тогда была 2.4. С тех пор пересобираю его под каждой новой версией — проблем не было.

Z>Типоголизм я особенно не трогал — мне нужен был язык типа SML (дататипы, паттерн-матчинг, немного RAII и интероп с Java) — все это я в принципе получил, хотя из-за аннотаций типов порой трудно уместиться в 80 колонок.

Z>Если мне придется еще что-нибуть писать под JVM — разумеется выберу Скалу, а под Net: F#

Z>Сам Одерски некоторое время назад оценивал зрелость компилятора на уровне javac 1.4 (он был одним из разработчиков — если кто не знает).

Я где-то с годик назад смотрел скалу и вроде как паттерн матчинг был там совсем никакой, вроде как можно было делать сопоставление только для одного объекта, или я это путаю скалу с чем-то другим?