Готова ли Scala к использованию? - Декларативное программирование

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

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

Прошло некоторое время и возможно пора сделать апдейт. Scala прет на всех парах: 6 книг, прилично поддерживается всеми основными java-ide (Eclipse, Netbeans, IDEA), ее благословил Гослинг. Создатель Groovy, James Strachan, сказал что не стал бы делать Groovy, знай он о Scala в 2003 году.
Для тех, кому это важно, открыли страницу Scala in the Enterprise — где о положительном опыте использования пишут Twitter, Électricité de France Trading, Siemens, Sony Pictures Imageworks и.т.д

Такие дела.

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

T>ghc?
T>haskell-libs?
T>ghc+haskell-libs?

Haskell крут, ведь на нем написана такая крутая вещь, как Haskell!

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

LP>void fun(a) //хз что сюда придет
LP>{
LP> a.foo();
LP> b.bar();
LP>}

LP>Сделай, пожалуйста, мне стат. связывание foo и ошибку компиляции на bar.

Unknown identifier `b' говорит.

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

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

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

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

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

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

Здравствуйте, Аноним, Вы писали:

А> Как я понял, в Scala принято, как в Groovy получать содержимое текстового
A> файла в строку вызоводм метода s=File.getLines
А> А что, если у меня файл из пары гигов знаков, ну к примеру, лог? Мне не хватит памяти его весь вычитать.

Так getLines возвращает итератор (т.е. ленивый список), он не грузит сразу все в память. Поэтому в памяти хранится только текущая строчка.
Соответственно filter тоже будет порождать новый итератор.

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

А>>Есть новый pdf

VD>А ссылка то где?

http://www.scala-lang.org/sites/default/files/sids/odersky/Sat,%202009-05-30,%2012:51/collections.pdf

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

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

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

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

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

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

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

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

Не глупое. Scala это лестница, la Scala. Лестница ведущая выше, и выше, и выше, и выше...

Как я понял, в Scala принято, как в Groovy получать содержимое текстового файла в строку вызоводм метода s=File.getLines

А что, если у меня файл из пары гигов знаков, ну к примеру, лог? Мне не хватит памяти его весь вычитать. Как в этом случае поступают? Да, если надо погрепать, т.е. выделить только строки, содержащие какую-то подстроку, то можно как-то getLines скормить фильтр, File.getLines filter {smthn}. А если мне кажду строку например надо преобразовать и записать в базу? Как вообще в таких случаях поступают в ФЯ, ФП?
Во всех блогах объясняют детали параметризации типов и тонкости карринга и хвостовой рекурсии, а куда податься новичку столкнувшемуся с практической задачей в новой обстановке?

В Scala даже while (b=stream.getbyte !=-1 ){} не работает, как в java, ибо присвоение возвращает всегда Unit

eao197 пишет:

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

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

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

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

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

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

Posted via RSDN NNTP Server 2.1 beta

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

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

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

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

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

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

C>>>Недавно пробовал ещё раз. Scala в IDEA уже годиться для промышленного использования, единственное чего не хватает — это нормального отладчика с demangling'ом символов.
T>>Очень меня порадовало это "я попробовал. для промышленного использование годится."

C>Да.
C>Я считаю, что язык не годен для промышленного использования в больших проектах, пока для него нет нормальной IDE.

Да-да. А нормальность IDE определяется исключительно Cyberax.

Практически все IDE проходят у него сертификацию.

C>Я считаю, что язык не годен для промышленного использования в больших проектах, пока для него нет нормальной IDE.

Есть мнение, что если языку требуется навороченная IDE, то с этим языком что-то не так, и IDE играет роль костыля для него.

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

C>>Я считаю, что язык не годен для промышленного использования в больших проектах, пока для него нет нормальной IDE.

V>Есть мнение, что если языку требуется навороченная IDE, то с этим языком что-то не так, и IDE играет роль костыля для него.

Да даже если нужен простой текстовый редактор, да и вообще компьютер, у языка уже большие проблемы.

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

C>>Я считаю, что язык не годен для промышленного использования в больших проектах, пока для него нет нормальной IDE.
V>Есть мнение, что если языку требуется навороченная IDE, то с этим языком что-то не так, и IDE играет роль костыля для него.
Нет, IDE просто необходима в больших проектах, где исходников больше, чем один человек может охватить.

И нет, REPL и крутость языка не являются заменой.

Понимаю, для Хаскелистов это сложно представить — они обычно работают над небольшими проектами.

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

V>Есть мнение, что если языку требуется навороченная IDE, то с этим языком что-то не так, и IDE играет роль костыля для него.

Да, есть такое мнение. Оно ошибочно.

Здравствуйте, Аноним, Вы писали:

А>В 2.8 будет куча глобальных изменений, которые ломают весь предыдущий код.

Примеры изменений, которые ломают весь предыдущий код — в студию.

Доброго дня!

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

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

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

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

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

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

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

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

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

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

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

eao197 пишет:

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

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

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

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

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

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

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

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

Posted via RSDN NNTP Server 2.1 beta

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

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

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

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

eao197 пишет:

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

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

Posted via RSDN NNTP Server 2.1 beta

VladD2 пишет:

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

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

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

Posted via RSDN NNTP Server 2.1 beta

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

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

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

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

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

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

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

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

Ну нет — разница между компилятором и интерпретатором на практике весома, груба и зрима.
Здесь представлена демонстрация разницы для 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"});
    }
}

... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>

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

MZ>VladD2 пишет:

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

Здравствуйте, 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 когда нельзя. Чудес не бывает.

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

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

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

Чудес не бывает, но для очень большого процента кода возможен статический вывод типов, притом используется спекулятивный вывод, то есть для одного и того же куска динамического кода генерируются несколько вариантов статически типизированного с разными типами, плюс еще используется прогон динамического кода со сбором статистики
о типах. Все это частично реализованно в PyPy, и практически полностью для Smalltalk.

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

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

Путаете.

eao197 пишет:

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

Так тогда вам и Java не пойдёт, вам С/С++ надо.

Posted via RSDN NNTP Server 2.1 beta

LaPerouse пишет:

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

Так а в обычной Java-программе что, нет RTTI ? Нет указателей на
вездесущий java.lang.Object ?

Posted via RSDN NNTP Server 2.1 beta

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

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

MZ>Так тогда вам и Java не пойдёт, вам С/С++ надо.

C++ у меня уже есть. Теперь хочется чего-нибудь более лаконичного и безопасного, с большими библиотеками (особенно для buzz-технологий вроде XML/HTTP/SOAP и пр.).

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

MZ>LaPerouse пишет:

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

MZ>Так а в обычной Java-программе что, нет RTTI ? Нет указателей на
MZ>вездесущий java.lang.Object ?

RTTI — он на то и ртти, что доступен во время выполнения и к компиляции ни малейшего отношения не имеет. java.lang.Object тоже абсолютно не при чем.

возьмем динамический код (просьба не смущаться на синтаксис явы)

class A
{
public void foo()
{
}
}

void main()
{
A a = new A();
foo(a);
}

void fun(a) //хз что сюда придет
{
a.foo();
b.bar();
}

Сделай, пожалуйста, мне стат. связывание foo и ошибку компиляции на bar.

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

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

MZ>Так тогда вам и Java не пойдёт, вам С/С++ надо.

Глупости. За пару миллисекунд на Java можно довольно много чего сделать. Особенно, после того как она "прогреется" и разгонится JITом.

А>Так getLines возвращает итератор (т.е. ленивый список), он не грузит сразу все в память. Поэтому в памяти хранится только текущая строчка.
А>Соответственно filter тоже будет порождать новый итератор.

Как я понял из http://spyced.blogspot.com/2007/12/scala-first-impressions.html?showComment=1199299560000#c5397991407658524703

scala.io.Source and I see you're using it here. There is a small problem with it, it loads the entire file in memory. The code in my file was used to process some large files which caused an out of memory exception if I used scala.io.Source.

грузит. Т.е. сначала грузится весь Source, а потом на массив в памяти получаем итератор

А> Т.е. сначала грузится весь Source, а потом на массив в памяти получаем итератор

Может тогда это так и было, но это давно исправлено (В 2.7.0 такого уже нет).

Возможно надо было создать новую ветку... сорри

Вопрос №1: для работы с классами без classOf[ClassName] (обращаться просто по имени) ещё ничего не придумали?
Про

def fun[T](params...)(implicit mfst : scala.reflect.Manifest[T]) =...

мне известно, но это довольно ограниченное решение

Вопрос №2: пусть и с `implicit mfst : scala.reflect.Manifest[T]` — можно ли сделать оператор (я знаю что это метод) вида

someObject myOperator [SomeClass]

?
Лучше бы конечно без квадратных скобок, но, я так понимаю, без них никуда.

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

E>Собственно, вопрос упирается в то, считает ли кто-нибудь Scala достаточно стабильным языком, для того, чтобы тратить ресурсы на создание кодовой базы на Scala.

А зачем эта информация нужна? Ну, кто-то считает, кто-то не считает.
Ведь только тебе решат подойдет она тебе или нет. Качай последнюю версию, качай интеграцию с ёклипсом и пробуй.
А там, или подойдет, или нет.

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

Ну, так мелкий проект написанный чисто для развлечения (и возможно решающий нужную задачу) поможет тебе это понять.

А вообще, языку уже не мало лет. Сам он пишется на себе и есть несколько проектов развиваемых на нем. Он просто не может быть не рабочим. Другое дело интеграция с ёклипсом/идеей и инфраструктура. Тут нужно опять же пробовать. Если все плохо, то или решат будешь ли ты мириться с этими проблемами, или бросать.

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

В связи с чем у меня к вам вопрос: как вы оцениваете сложность применения скалы в реальных проектах? Например:

1) Скала? В реальных проектах? Вы бы ещё на хаскеле писали;
2) Первые полгода тяжело, а потом привыкаешь;
3) Я вообще-то раньше на хаскеле писал, а на скале заставили; фигня это для начинающих программистов.

И связанный с ним второй вопрос: а другие участники проекта на скале вместе с вами могут писать? Варианты ответа вроде:

1) Говно вопрос!
2) Ну, пришлось объяснить им что к чему, но разобрались и сейчас пишут;
3) Нет, это для гениев, а гении не все;
4) Скала? В реальных проектах? См. вопрос 1.

В общем, что скажете?

Результаты опроса http://community.livejournal.com/ru_scala/6790.html

VD>А вообще, языку уже не мало лет. Сам он пишется на себе и есть несколько проектов развиваемых на нем. Он просто не может быть не рабочим.

Кстати, одно из преимуществ java (перед теми же плюсами) была высокая скорость компиляции кода. Как с этим у скалы? Не придется ли до-олго ждать перекомпиляции проекта?

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

VD>>А вообще, языку уже не мало лет. Сам он пишется на себе и есть несколько проектов развиваемых на нем. Он просто не может быть не рабочим.

V>Кстати, одно из преимуществ java (перед теми же плюсами) была высокая скорость компиляции кода. Как с этим у скалы? Не придется ли до-олго ждать перекомпиляции проекта?

Bootstrap компиляция компилятора и базовых библиотек занимает около получаса.

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

VD>А вообще, языку уже не мало лет. Сам он пишется на себе и есть несколько проектов развиваемых на нем. Он просто не может быть не рабочим. Другое дело интеграция с ёклипсом/идеей и инфраструктура. Тут нужно опять же пробовать. Если все плохо, то или решат будешь ли ты мириться с этими проблемами, или бросать.
Недавно пробовал ещё раз. Scala в IDEA уже годиться для промышленного использования, единственное чего не хватает — это нормального отладчика с demangling'ом символов.

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

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

VD>>А вообще, языку уже не мало лет. Сам он пишется на себе и есть несколько проектов развиваемых на нем. Он просто не может быть не рабочим. Другое дело интеграция с ёклипсом/идеей и инфраструктура. Тут нужно опять же пробовать. Если все плохо, то или решат будешь ли ты мириться с этими проблемами, или бросать.
C>Недавно пробовал ещё раз. Scala в IDEA уже годиться для промышленного использования, единственное чего не хватает — это нормального отладчика с demangling'ом символов.

Выделенное означает "они добили контекстное дополнение! я ж без него, как без рук."

Или что там ещё тебе надо было.

Очень меня порадовало это "я попробовал. для промышленного использование годится."

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

C>>Недавно пробовал ещё раз. Scala в IDEA уже годиться для промышленного использования, единственное чего не хватает — это нормального отладчика с demangling'ом символов.
T>Выделенное означает "они добили контекстное дополнение! я ж без него, как без рук."
Угу.

T>Или что там ещё тебе надо было.
Компиляция, отладка, навигация по проекту, инспекции.

T>Очень меня порадовало это "я попробовал. для промышленного использование годится."

Да.

Я считаю, что язык не годен для промышленного использования в больших проектах, пока для него нет нормальной IDE.

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

N>Да даже если нужен простой текстовый редактор, да и вообще компьютер, у языка уже большие проблемы.

А то вы не знаете языка с несколько-тысячелетней историей, которому только бумага с ручкой нужна?

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

C>>Я считаю, что язык не годен для промышленного использования в больших проектах, пока для него нет нормальной IDE.
T>Да-да. А нормальность IDE определяется исключительно Cyberax.
Нет, просто достаточно посмотреть работает ли в ней контекстный автокомплит — это самая главная вещь, из которой строится уже всё остальное. Это кто угодно может сделать.

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

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

C>>>Я считаю, что язык не годен для промышленного использования в больших проектах, пока для него нет нормальной IDE.
T>>Да-да. А нормальность IDE определяется исключительно Cyberax.
C>Нет, просто достаточно посмотреть работает ли в ней контекстный автокомплит — это самая главная вещь, из которой строится уже всё остальное. Это кто угодно может сделать.

Ну, вот в notepad работает контекстный автокомплит (что бы это не значило).

C>>>Я считаю, что язык не годен для промышленного использования в больших проектах, пока для него нет нормальной IDE.
V>>Есть мнение, что если языку требуется навороченная IDE, то с этим языком что-то не так, и IDE играет роль костыля для него.
C>Нет, IDE просто необходима в больших проектах, где исходников больше, чем один человек может охватить.

А какой примерный минимальный размер такого большого проекта? (в строках кода)
Т.е. где грань когда уже становится нужна навороченная IDE?

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

C>>Нет, просто достаточно посмотреть работает ли в ней контекстный автокомплит — это самая главная вещь, из которой строится уже всё остальное. Это кто угодно может сделать.
T>Ну, вот в notepad работает контекстный автокомплит (что бы это не значило).
Ну вот, notepad не является IDE.

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

V>>>Есть мнение, что если языку требуется навороченная IDE, то с этим языком что-то не так, и IDE играет роль костыля для него.
C>>Нет, IDE просто необходима в больших проектах, где исходников больше, чем один человек может охватить.
V>А какой примерный минимальный размер такого большого проекта? (в строках кода)
V>Т.е. где грань когда уже становится нужна навороченная IDE?
По общепринятому понятию — около 200000 строк.

Честно говоря, я вообще таких проектов на Хаскелле не знаю.

V>>>>Есть мнение, что если языку требуется навороченная IDE, то с этим языком что-то не так, и IDE играет роль костыля для него.
C>>>Нет, IDE просто необходима в больших проектах, где исходников больше, чем один человек может охватить.
V>>А какой примерный минимальный размер такого большого проекта? (в строках кода)
V>>Т.е. где грань когда уже становится нужна навороченная IDE?
C>По общепринятому понятию — около 200000 строк.
C>Честно говоря, я вообще таких проектов на Хаскелле не знаю.
Ну, например сам ghc > 200k строк только на хаскеле.

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

C>>По общепринятому понятию — около 200000 строк.
C>>Честно говоря, я вообще таких проектов на Хаскелле не знаю.
V>Ну, например сам ghc > 200k строк только на хаскеле.
Оно не считается, его пишут те, кто идеально знают Хаскелл.

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

V>>Ну, например сам ghc > 200k строк только на хаскеле.
C>Оно не считается, его пишут те, кто идеально знают Хаскелл.

точнее сами его и создают

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

N>Bootstrap компиляция компилятора и базовых библиотек занимает около получаса.

Саму Скалу компилить из исходников? Зачем?

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

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

C>>>Нет, просто достаточно посмотреть работает ли в ней контекстный автокомплит — это самая главная вещь, из которой строится уже всё остальное. Это кто угодно может сделать.
T>>Ну, вот в notepad работает контекстный автокомплит (что бы это не значило).
C>Ну вот, notepad не является IDE.

Как так? Ведь работает?

PS
Всё, ухожу, ухожу, ухожу.

Не гоже мне, хаскель фаром редактирующему, рассуждать о высотах промышленного программирования.

Оставлю это более гордым, с меньшей рефлексией.

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

C>>>>Нет, просто достаточно посмотреть работает ли в ней контекстный автокомплит — это самая главная вещь, из которой строится уже всё остальное. Это кто угодно может сделать.
T>>>Ну, вот в notepad работает контекстный автокомплит (что бы это не значило).
C>>Ну вот, notepad не является IDE.
T>Как так? Ведь работает?
Ой, я не то написал. Следует читать: "Ну вот, notepad является IDE."

Здравствуйте, Аноним, Вы писали:

N>>Bootstrap компиляция компилятора и базовых библиотек занимает около получаса.

А>Саму Скалу компилить из исходников? Зачем?

здесь
В trunk head есть некоторые новые фичи, которые еще не вошли в бинарные дистрибутивы.

Как может быть инструмент готов к промышленному использованию, если он активно меняется?
Я начал использовать Java с 1.4.
Кардинально она не поменялась. По крайней мере все что работало в 1.4 работает в 1.5 и 1.6.
Может есть какие-то вещи, которые не работают, но я с ними не сталкивался.
А что в Scala?
В 2.8 будет куча глобальных изменений, которые ломают весь предыдущий код.
Да — это нужные и полезные изменения.
Но кто станет писать что-то серьезное на инструменте, который через пол года изменится так, что код работать не будет?

Кроме того некоторые вещи в Scala как-то надуманы.
Например Operator Precedence.
Какая-то эта фича очень синтетическая.

Вобщем смотреть на Scala можно, играться с ней тоже можно, даже писать что-то не для продакшена можно.
Но не больше.

PS.
Слышал краем уха что C#, вернее дотнет, от версии к версии тоже местами не очень совместим.
Это так?

Здравствуйте, Аноним, Вы писали:

А>Слышал краем уха что C#, вернее дотнет, от версии к версии тоже местами не очень совместим.
А>Это так?

Нет. Версии дотнета 2.0, 3.0, 3.5 использовали один и тот же рантайм версии 2.0.50727. Следующая версия Фреймворка будет^W основана на новой версии CLR, но 1) совместимость остаётся, 2) разные версии фреймворка спокойно уживаются side by side.

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

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

V>>>>Есть мнение, что если языку требуется навороченная IDE, то с этим языком что-то не так, и IDE играет роль костыля для него.
C>>>Нет, IDE просто необходима в больших проектах, где исходников больше, чем один человек может охватить.
V>>А какой примерный минимальный размер такого большого проекта? (в строках кода)
V>>Т.е. где грань когда уже становится нужна навороченная IDE?
C>По общепринятому понятию — около 200000 строк.

C++/Java строки надо делить на 10.

C>Честно говоря, я вообще таких проектов на Хаскелле не знаю.

ghc?

haskell-libs?

ghc+haskell-libs?

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

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

C>>>По общепринятому понятию — около 200000 строк.
C>>>Честно говоря, я вообще таких проектов на Хаскелле не знаю.
V>>Ну, например сам ghc > 200k строк только на хаскеле.
C>Оно не считается, его пишут те, кто идеально знают Хаскелл.

Нет, не идеально.

Он же меняется постоянно.

N>Примеры изменений, которые ломают весь предыдущий код — в студию.

Примеры привести не могу.
Но читая их мэйллист вижу что переколбасили массивы, и идет активное обсуждение изменения for comprehension.
Если что-то у пользователей не работает, то все время спрашивают, какую версию Scala они используют — 2.8 или предыдущие.

Тот же Range изменился.

N>Примеры изменений, которые ломают весь предыдущий код — в студию.
Почитайте вот это — Why Scala 2.8 instead of Scala 3.0?

Здравствуйте, Аноним, Вы писали:

А>Почитайте вот это — Why Scala 2.8 instead of Scala 3.0?

Вчера читал.

N>Вчера читал.

И то что новые релизы не совместимы со старыми — вас не пугает?

Здравствуйте, Аноним, Вы писали:

N>>Примеры изменений, которые ломают весь предыдущий код — в студию.
А>Почитайте вот это — Why Scala 2.8 instead of Scala 3.0?
Там о бинарной совместимости — это нерелевантно ломанию кода.

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

C>>По общепринятому понятию — около 200000 строк.
T>C++/Java строки надо делить на 10.

И из-за сложности Хаскелля на 20 умножить.

C>>Честно говоря, я вообще таких проектов на Хаскелле не знаю.
T>ghc?
T>haskell-libs?
T>ghc+haskell-libs?
А что-нибудь не библиотечно-компиляторное?

Здравствуйте, Аноним, Вы писали:

А>И то что новые релизы не совместимы со старыми — вас не пугает?

Бинарная несовместимость решается перекомпиляцией проекта.

N>Бинарная несовместимость решается перекомпиляцией проекта.

Нет.
Почитайте тред "Scala modularisation withdrawl".
Особенно сообщения от разработчика Lift.

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

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

C>>>По общепринятому понятию — около 200000 строк.
T>>C++/Java строки надо делить на 10.

C>И из-за сложности Хаскелля на 20 умножить.

Это взгляд менеджера, не программиста. Программист будет делить, поскольку сложность Хаскеля делает программирование проще.

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

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

C>>>Честно говоря, я вообще таких проектов на Хаскелле не знаю.
T>>ghc?
T>>haskell-libs?
T>>ghc+haskell-libs?
C>А что-нибудь не библиотечно-компиляторное?

Кстати, спроси в galois connections. http://galois.com

Здравствуйте, Аноним, Вы писали:

А>PS.
А>Слышал краем уха что C#, вернее дотнет, от версии к версии тоже местами не очень совместим.
А>Это так?

Это бред. Сдается мне, что твои рассказы про Скалу не далеко от этих слухов ушли.

Здравствуйте, Аноним, Вы писали:

А>Если что-то у пользователей не работает, то все время спрашивают, какую версию Scala они используют — 2.8 или предыдущие.

Дык, логично. Есть баги исправленные в новой версии и есть фичи появившиеся в новой версии. Если кто-то использует старую версию, то не странно, что он нарывается на баги и на отсутствие фич.

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

А>>И то что новые релизы не совместимы со старыми — вас не пугает?

N>Бинарная несовместимость решается перекомпиляцией проекта.

А если проект битстрипный?

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

N>>Бинарная несовместимость решается перекомпиляцией проекта.

VD>А если проект битстрипный?

Ну вот бутстрипность компилятора скалы и доказывает, что никаких сверх-несовместимостей нет.

VD>Это бред. Сдается мне, что твои рассказы про Скалу не далеко от этих слухов ушли.

Я не знаю Скалу.
Но вы можете просто почитать мейллист пользователей и разработчиков скалы и увидеть какой переполох устроил выход скалы 2.8

"Скала", это компьютерная система , которая стояла на печально известном Чернобыльском реакторе.
Хотя в этот раз может будет совсем другая scala.

N>Ну вот бутстрипность компилятора скалы и доказывает, что никаких сверх-несовместимостей нет.

Сверх-нет. Но какие-т овсе таки есть?

VD>Это бред. Сдается мне, что твои рассказы про Скалу не далеко от этих слухов ушли.

И насчет бреда — я же сказал что про C# я слышал краем уха. Не надо так расстраиваться.

Z>Там о бинарной совместимости — это нерелевантно ломанию кода.

Но разве там сказано, что достаточно перекомпилить с новой Скалой?
Если так — значит я был не прав.

Здравствуйте, Аноним, Вы писали:

А>И насчет бреда — я же сказал что про C# я слышал краем уха. Не надо так расстраиваться.

Я не расстраиваюсь. Но такие слухи характерны бабушкам сидящим на лавочках во дворе, а не программистам.

VD>Я не расстраиваюсь. Но такие слухи характерны бабушкам сидящим на лавочках во дворе, а не программистам.

Это было не утверждение, а вопрос

>>Это так?

Здравствуйте, Аноним, Вы писали:

А>А что в Scala?
А>В 2.8 будет куча глобальных изменений, которые ломают весь предыдущий код.

Кстати, есть такое дело. Скачал себе IntelliJ IDEA CE, к ней новый плагин Scala. Так вот, он не видит в упор простейший scala код, грит symbol scala not found. Глянул, а с плагином идет Scala 2.8 b2

Здравствуйте, Аноним, Вы писали:

А>Как может быть инструмент готов к промышленному использованию, если он активно меняется?
А>В 2.8 будет куча глобальных изменений, которые ломают весь предыдущий код.
А>Да — это нужные и полезные изменения.
А>Но кто станет писать что-то серьезное на инструменте, который через пол года изменится так, что код работать не будет?

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

Взгляните хотя бы на serializable continuations!

	От:	Partisan
	Дата:	01.03.09 18:43
	Оценка:	21 (2) -5

	От:	z00n
	Дата:	02.08.09 17:12
	Оценка:	73 (6)

От:	nikov	http://www.linkedin.com/in/nikov
Дата:	20.10.09 10:20
Оценка:	+1

От:	lomeo	http://lomeo.livejournal.com/
Дата:	02.03.09 19:28
Оценка:	+1

От:	eao197	http://eao197.blogspot.com
Дата:	01.03.09 20:42
Оценка:	+2

От:	Oksana Gimmel	http://oksana-gimmel.blogspot.com/
Дата:	21.10.09 21:37
Оценка:	47 (1)

	От:	Аноним
	Дата:	17.07.09 18:11
	Оценка:	1 (1)

От:	Qbit86	https://twitter.com/qbit86
Дата:	02.03.09 10:40
Оценка:	-1

От:	thesz	http://thesz.livejournal.com
Дата:	18.10.09 08:55
Оценка:

От:	D. Mon	http://thedeemon.livejournal.com
Дата:	18.10.09 13:39
Оценка:	+1

От:	VladD2	www.nemerle.org
Дата:	01.03.09 23:53
Оценка:

	От:	Rtveliashvili Denys
	Дата:	05.03.09 16:01
	Оценка: