Re[12]: Oberon???????????????????????????????????
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.10.04 10:07
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>Некоторые вещи, от которых ты сейчас так плюешься, перекочуют в С# в самом ближайшем будущем.


Не дай бог.

S>Я, конечно же, схитрил. Для того, чтобы получить полный аналог SmallTalk, пршлось бы добавить метод ToDo в System.Int32(как это, собственно, и сделано в SmallTalk.):

S>
S>1.ToDo(10, delegate(int each) { Transcript.Show(each); });
S>


Где бы нарыть смайлик плюющий через плече и рестящийся?

В общем, за такое нужно
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Oberon???????????????????????????????????
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.10.04 10:07
Оценка:
Здравствуйте, FR, Вы писали:

FR>Слушай до меня не доходит, изобрази в коде то что хотелось бы.


Вопрос на чем?

Ну, нечто вроде:

int[] a = { 1, 2, 3 };
a = a + 4; // a == { 1, 2, 3, 4 }


Т.е. не
a.append(4);

а просто арифметика или еще что на списках.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Oberon???????????????????????????????????
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 24.10.04 10:39
Оценка: 13 (2) +1
Здравствуйте, VladD2, Вы писали:
VD>Не дай бог.
Поздняк метаться. C# 2.0 already came.

VD>Где бы нарыть смайлик плюющий через плече и рестящийся?


VD>В общем, за такое нужно
Помяни мои слова, Влад, через год ты сам будешь приводить подобные тексты в битвах с апологетами конкурирующих платформ
Конечно же, данный конкретный пример плох. По крайней мере нам с тобой легче читать именно
foreach(int each in Range(1, 10))
{
  Transcript.Show(each);
}

Но вот развитие идей разделения генерации последовательностей и их обработки неизбежно приводит к чему-то типа:

public void PrintNonDividable(Range r, int divisor)
{
   Print(r.Filter(delegate(int item){return (item % divisor) != 0;}));
}

Что, имхо, гораздо лучше чем
public void PrintNonDividable(Range r, int divisor)
{
  Range r2 = new Range();
  foreach(int item in r)
    {
      if ((item % divisor) != 0)
          r2.Append(item);
    }
  Print(r2);
}

И лучше по двум основным причинам:
1. Меньше строчек — меньше ошибок.
2. Можно оперировать бесконечными (или очень длинными) последовательностями значительно оптимальнее. Этот Range запросто может быть генератором, а не коллекцией. Наложение Filter на него совершенно не обязательно вынуждает немедленно получить другую коллекцию. Собственно, yield-инг результатов (возможно) начнется только на месте употребления. И все это мы имеем совершенно забесплатно.
Цена этому — обучение программистов новой конструкции — анонимным методам.
Получив в руки такой могучий инструмент, сразу хочется выкинуть все "лишнее". Ведь теперь нам собственно никакие управляющие конструкции не нужны — мы можем их эмулировать при помощи обычных методов
Что такое If как не метод, принимающий булевый делегат и два воид-делегата?
Цикл превращается в метод Apply у IEnumerable. Ну и так далее. Страшно, да?
Вот к чему приводит стремление к "нормализации"! Сахар в языке — вещь полезная .
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[17]: Oberon?
От: eugals Россия  
Дата: 24.10.04 10:55
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Тут долго пояснять.

Вряд ли во всём перечисленном у шарпа есть существенные преимущества.
Наверняка кое в чем он даже уступает.

VD> Это и динамическая загрузка скомпилированных модулей,

Без проблем. Питон динамический язык, соответственно и динамическая загрузка модулей в нем имеется. Отгрузка и перезагрузка, кстати, тоже
VD> и интерфейсы,
В питоне, как и в смолтоке, любому объекту можно послать любое сообщение. Куда уж гибче интерфейс.
VD> и рефлекшен,
Ну, тут сам б-г велел. Разве что называется по-другому (кстати, имхо, ближе к сути): интроспекшн
VD> и дизайнеры компонентов/контролов,
А что дизайнеры? Под питон еть порт всех популярных оконных (и вообще, компонентных) библиотек/технологий: PyQT, PythonNet, PyCOM, PyXPCOM, PyVCL...
Вот я, например, одним из таких приложений сейчас занимаюсь
Автор: eugals
Дата: 04.08.04

VD> и генерация мсила,
Опять же, в динамическом ЯП, это всё гораздо прозрачнее, чем Reflection.Emit.
Вот пример функции, которая генерирует новый класс (сколько раз её позовешь, столько раз и сгенерирует):
def genClass( ):
    class AClass( object):
        # member declarations
    return AClass

VD>и интеграция с другими языками.
Смотри выше. Порты есть. В том числе и в дотнет. Плюс удобное Python-Си апи, А С(++), несмотря на майкрософтовский прессрелизы, всё ещё главный мировой язык для разработки библиотек.

VD>В общем, возможность манимулирования не кодом, а готовыми бинарными модулями.

Ну, в питоне свой формат прекомпилированных файлов. Вполне себе бинарные модули. Не хуже мсильных сборок.

VD> Причем практически без потери производительности.

Вот, собственно, ключевая оговорка
Здесь да, спорить бессмысленно — шарп пока быстрее.
Зато питон гибче и лаконичнее. Плюс у него есть много других преимуществ (встроенные возможности АОП, например).
Но только какое отношение преимущество шарпа в скорости имеет к заявленным тобой "компонентным возможностям"? Имхо, второстепенное.

ЗЫЖ На хочется в очередной раз начинать на этом форуме холивар Static vs. Dynamic.
_vovin, в свое время, довольно хорошо про это написал тут. Вряд ли я смогу добавить что-то принципильно новое. А даже если и смогу, тебя всё равно не переубедить, это общеизвестно
... << RSDN@Home 1.1.4 @@subversion >>
Интерактивный режим питона
От: eugals Россия  
Дата: 24.10.04 10:55
Оценка: 27 (3) :)
Здравствуйте, VladD2, Вы писали:

VD>Еще раз. Нет проблем сделать снипит-компилятор скроющий все детали.

Питоновский интерактивный режим простым снипит-компилятором не взять.
Он вот что умеет:
>>> a = 1
>>> b = "строка"
>>> # - вот ребята, сейчас мы с вами объявили свои первые переменные
>>> # давайте посмотрим, добавились ли они в глобальную область имен:
>>> dir()
['__builtins__', '__doc__', '__name__', 'a', 'b']
>>> # - Видите! Добавились!
>>> # Обратите внимание, что кроме наших переменных в ней уже присутствовали 
>>> # несколько встроенных системных имен.
>>> # Ну, что такое __name__ и __doc__ я вам рассказывал на предыдущм занятии,
>>> # а сейчас давайте посмотрим на __builtins__ - это модуль содержащий все 
>>> # встроенные функции и переменные.
>>> # Давайте посмотрим, что он содержит:
>>> dir(__builtins__)
['ArithmeticError', 'AssertionError', 'AttributeError', 'DeprecationWarning', 'E
OFError', 'Ellipsis', 'EnvironmentError', 'Exception', 'False', 'FloatingPointEr
ror', 'FutureWarning', 'IOError', 'ImportError', 'IndentationError', 'IndexError
', 'KeyError', 'KeyboardInterrupt', 'LookupError', 'MemoryError', 'NameError', '
None', 'NotImplemented', 'NotImplementedError', 'OSError', 'OverflowError', 'Ove
rflowWarning', 'PendingDeprecationWarning', 'ReferenceError', 'RuntimeError', 'R
untimeWarning', 'StandardError', 'StopIteration', 'SyntaxError', 'SyntaxWarning'
, 'SystemError', 'SystemExit', 'TabError', 'True', 'TypeError', 'UnboundLocalErr
or', 'UnicodeDecodeError', 'UnicodeEncodeError', 'UnicodeError', 'UnicodeTransla
teError', 'UserWarning', 'ValueError', 'Warning', 'WindowsError', 'ZeroDivisionE
rror', '_', '__debug__', '__doc__', '__import__', '__name__', 'abs', 'apply', 'b
asestring', 'bool', 'buffer', 'callable', 'chr', 'classmethod', 'cmp', 'coerce',
 'compile', 'complex', 'copyright', 'credits', 'delattr', 'dict', 'dir', 'divmod
', 'enumerate', 'eval', 'execfile', 'exit', 'file', 'filter', 'float', 'getattr'
, 'globals', 'hasattr', 'hash', 'help', 'hex', 'id', 'input', 'int', 'intern', '
isinstance', 'issubclass', 'iter', 'len', 'license', 'list', 'locals', 'long', '
map', 'max', 'min', 'object', 'oct', 'open', 'ord', 'pow', 'property', 'quit', '
range', 'raw_input', 'reduce', 'reload', 'repr', 'round', 'setattr', 'slice', 's
taticmethod', 'str', 'sum', 'super', 'tuple', 'type', 'unichr', 'unicode', 'vars
', 'xrange', 'zip']
>>> # - Воо-о-от. Постепенно мы с вами изучим, что все они означают.
>>> # Начнем, пожалуй, с функции dir(), которую я только что использовал.
>>> # Давайте помотрим, что нам скажет про неё другая встроенная функция (help)
>>> help(dir)
Help on built-in function dir:

dir(...)
    dir([object]) -> list of strings

    Return an alphabetized list of names comprising (some of) the attributes
    of the given object, and of attributes reachable from it:

    No argument:  the names in the current scope.
    Module object:  the module attributes.
    Type or class object:  its attributes, and recursively the attributes of
        its bases.
    Otherwise:  its attributes, its class's attributes, and recursively the
        attributes of its class's base classes.
                
>>> # ну и т.д.
... << RSDN@Home 1.1.4 @@subversion >>
Re[21]: Oberon???????????????????????????????????
От: eugals Россия  
Дата: 24.10.04 10:56
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>
VD>int[] a = { 1, 2, 3 };
VD>a = a + 4; // a == { 1, 2, 3, 4 }
VD>


a = [1, 2, 3]
a = a + [4]
... << RSDN@Home 1.1.4 @@subversion >>
Re[14]: Oberon???????????????????????????????????
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.10.04 11:35
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Поздняк метаться. C# 2.0 already came.


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

S>Но вот развитие идей разделения генерации последовательностей и их обработки неизбежно приводит к чему-то типа:


S>
S>public void PrintNonDividable(Range r, int divisor)
S>{
S>   Print(r.Filter(delegate(int item){return (item % divisor) != 0;}));
S>}
S>

S>Что, имхо, гораздо лучше чем
S>

Ну, то не так страшно.

S>public void PrintNonDividable(Range r, int divisor)
S>{
S>  Range r2 = new Range();
S>  foreach(int item in r)
S>    {
S>      if ((item % divisor) != 0)
S>          r2.Append(item);
S>    }
S>  Print(r2);
S>}
S>

S>И лучше по двум основным причинам:
S>1. Меньше строчек — меньше ошибок.

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

S>2. Можно оперировать бесконечными (или очень длинными) последовательностями значительно оптимальнее.


К сожалению, Шарп не оптимизирован под функциональный стиль. Писать то так можно, но это будет значтельно медленнее. Да и получается несколькь более громоздко нежели в чистых ФЯ или питоне.

Однако данную задачу проще режить так:
class Program
{
    public static IEnumerable<int> NonDividable(IEnumerable<int> range, int divisor)
    {
        foreach (int item in range)
            if (item % divisor != 0)
                yield return item;
    }

    static void Main(string[] args)
    {
        foreach (int value in NonDividable(XRange(10), 2))
            Console.Write(value + " ");
    }

    #region XRange Impl
    
    static IEnumerable<int> XRange(int len)
    {
        return XRange(0, len, 1);
    }

    static IEnumerable<int> XRange(int start, int len)
    {
        return XRange(start, len, 1);
    }

    static IEnumerable<int> XRange(int start, int len, int inc)
    {
        int count = (len - start) / inc;
        for (int val = start, i = 0; i < count; i++, val += inc)
            yield return val;
    }

    #endregion
}



S> Этот Range запросто может быть генератором, а не коллекцией.


В дотнете это называется enumerable, т.е. энумератором, перечеслителем.

Но проблема в том, что это объект, а значит несколько медленнее чем лобовые for-ы с ифами. Хотя медленее чем в Питоне не будет.

Однако, любымый для функциональщиков Фибоначи в функцниональном стиле на Шарпе вылевается в полную задницу с точки зрения производительности, так как ни компилятор Шарпа, ни джит не устраняют рекурсию в таких случаях. Попробуй ради хохмы эту реализацию:
static long Fib(int n)
{
    return n < 2 ? 1 : (Fib(n - 1) + Fib(n - 2));
}
...
foreach (int value in NonDividable(XRange(10), 2))
    Console.Write(value + " ");

В Питоне кстати оптимизации тоже нет, но есть функция memoize делающая ее "врукопашную".


S> Наложение Filter на него совершенно не обязательно вынуждает немедленно получить другую коллекцию. Собственно, yield-инг результатов (возможно) начнется только на месте употребления. И все это мы имеем совершенно забесплатно.


Гы. Довольно за дорого.

S>Цена этому — обучение программистов новой конструкции — анонимным методам.


Ага. И обучение компилятора человеческой оптимизации.

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


Особенно забавно использовать yield return без управляющих конструкций.

S>Что такое If как не метод,


Как что? Управляющая конструкция. Вот "? x : y" — это функция. Вот только в нее yield return не воткнешь. Другая, понимаш, парадигма. И кстати, она почему-то мне очень понятна и приятна.

S> принимающий булевый делегат и два воид-делегата?


Что такое "воид-делегата"?

S>Цикл превращается в метод Apply у IEnumerable. Ну и так далее. Страшно, да?


Страшно, что попади это дело в руки орлам вроде тех что писали СТЛ и выйдет СТЛ.

S>Вот к чему приводит стремление к "нормализации"! Сахар в языке — вещь полезная .


Я не сказал бы, что делегаты — это сахар. А анонимные методы логическое их развитие. Жать только что без соотвествующей оптимизации применение данных фич негативно скажется на производительности.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Мэйнстрим vs. Самосовершенствование :)))
От: Зверёк Харьковский  
Дата: 24.10.04 11:51
Оценка: 12 (1) +4
Здравствуйте, VladD2, Вы писали:

VD>Оберон — это мертвях. Учить ему будущих программистов все равно что учить латыни будущих переводчиков. Неужели нехватает живых языков? Чем та же Ява или Шарп хуже?


Дорогой Влад!

"Я тебе один умный вещь скажу, только ты не обижайся" (с) мой папа.

Наблюдаю я уже который день за этой дискуссией вокруг Оберона-СмолТолка-Питона-и др. и возникло у меня такое впечатление.
Имхо, ты везде приводишь более-менее верные и логичные аргументы, но не прав в главной своей мысли: "Все пишут на Яве и Шарпе, поэтому учить больше ничего не надо".
Я считаю, что изучение других языков программирования идет не в минус (забиваем голову ненужной информацией), а в плюс. И не потому, что СмолТолк кому-то может пригодиться (ой, сумлеваюсь), а по очень простой причине: расширение кругозора. Просто понять, что "и такое бывает". Подцепить полезный метод или идею. В конце концов (в парадигме начального вопроса Валерия Викторовича) — просто осознать, "что не в любом языке программирования есть фигурные скобки".

Возьмем, например, меня .
В контексте давнего спора про то, какой язык кому нравится, могу слегка скорректировать свое тогдашнее мнение: "я люблю С++ и пока это возможно, буду писать только на нем", но сейчас собираюсь покупать Рихтера про Шарп. Не потому, что хочу на него перейти — интересно, что нового, чем он отличается; как нужно "думать на Шарпе". А и кроме того, книжки, которые валяются на винте, и которые я уже изучил или собираюсь в ближайшем будушем, посвящены языкам: Ada, Assembler, Awk, C--, C++, C#, Delphi, Eiffel, Euphoria, Forth, Go!, Haskell, Java, Lisp, OCaml, Oz, Perl, PHP, Prolog, Python, Refal, Small, Smalltalk, Tcl, VB.

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

Во. Типа dixi.
FAQ — це мiй ай-кью!
Re[22]: Oberon???????????????????????????????????
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.10.04 12:32
Оценка:
Здравствуйте, eugals, Вы писали:

E>
E>a = [1, 2, 3]
E>a = a + [4]
E>


Это не то. То получается только через append . А тут на лицо склеивание списков. К тому же похоже в результате получается третий список ссылка на который попадает в a. Хотя это уже другой вопрос.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Oberon?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.10.04 12:32
Оценка:
Здравствуйте, eugals, Вы писали:

E>Без проблем. Питон динамический язык,


А Шарп статический. От того и быстрый кода порождает. Но при этом с компонентами все ОК.

E> соответственно и динамическая загрузка модулей в нем имеется. Отгрузка и перезагрузка, кстати, тоже


Вот тут бы я не радовался. Поле для ошибок. Переприсвоил имя и все поехало. Переменные не объявляются, а значит их можно создавать случайно. Они не типизированны, а нзначит тормоза. Это уже не компонентность, а интерпретируемость получается.

VD>> и интерфейсы,

E>В питоне, как и в смолтоке, любому объекту можно послать любое сообщение. Куда уж гибче интерфейс.

Ну, ОО в питое как раз мне совсем не понравилось. Странности на каждом шагу.
Что до гибкости... Везде нужен баланс. Без разумного подхода гибкость превращается в тормоза и баги. С твоими любимыми сообщениями большое приложение рассыпится от рантаймных багов. Интерфеейсы — это это средство выделения абстракции. Они не гибкие, и не жесткие. И их отсуствие — это большой минус для языка претендующего на звание ООЯ.

Забавно так же отсутствие модификаторов доступа (видимости). Все паблик, и все виртуальное. Во, блин, решение. Ни надежности, ни скорости. За-то забавнейшие конструкции вроде self в параметрах.

VD>> и дизайнеры компонентов/контролов,

E>А что дизайнеры?

Вот и я о том же. Компоненты типа есть. А что такое дизайнеры для них не знаем.

E> Под питон еть порт всех популярных оконных (и вообще, компонентных) библиотек/технологий: PyQT, PythonNet, PyCOM, PyXPCOM, PyVCL...


Во-во. Порт недо-технологий перехивших свой век. Зачем же нужены порты полноценному компонетному языку? Вот в дотнете все компонетны (вместе с компонетной моделью) написаны на Шарпе. И вписываются в среду и рантайм как будто они там всю жизнь были.

E>Вот я, например, одним из таких приложений сейчас занимаюсь
Автор: eugals
Дата: 04.08.04


Забавно. Ну, значит должен понимать сколько кода нуно докрутить к чистому Питону, чтобы с ним работать в компонентном стиле. А в дотнете все уже есть. И твой дизайнер делается за пару часов.

VD>> и генерация мсила,

E>Опять же, в динамическом ЯП, это всё гораздо прозрачнее, чем Reflection.Emit.

Еще раз. Прозрачность должна еще должна быть зачем-то нужна. Если я получаю в 10 раз блее медленное решение, то уж лучше я обойдусь менее прозрачным.


VD>>и интеграция с другими языками.

E>Смотри выше. Порты есть.

Нафиг порты? Нужно чтобы подключил модуль на другом языке и пльзуйся типами. Причем опять таки чтобы это не превратилось в пошаговую стратегию.

E> В том числе и в дотнет.


Гы. Питон в дотнете — это уже дотнет. Далее от питона просто ничего не требуется. Ну, разве что мало мальски прилично код сгенерировать.

E> Плюс удобное Python-Си апи, А С(++), несмотря на майкрософтовский прессрелизы, всё ещё главный мировой язык для разработки библиотек.


Да? И какие ты библиотеки на С++ знаешь? А на счет удобства. Что может быть удбонее чем просто использование в одном проекте длл-ек написанных на разных языках?

VD>>В общем, возможность манимулирования не кодом, а готовыми бинарными модулями.

E>Ну, в питоне свой формат прекомпилированных файлов. Вполне себе бинарные модули. Не хуже мсильных сборок.

На склько я знаю каждая версия Питона имеет отличный формат и по этому бинарниками никто не поьзуется. Более того они вроде не обязательны. Не создался и ладно...

VD>> Причем практически без потери производительности.

E>Вот, собственно, ключевая оговорка

Дык она даже не ключевая. Она базовая предпосылка. Т.е. дивиз такой, просто, просто насколько это можно, но не более просто чем нужно для получения производительного кода.

E>Здесь да, спорить бессмысленно — шарп пока быстрее.


Покая? Шарпу 2 года. И с каждым годом он становится все быстрее и быстрее. Думаю, ко времени когда МС начнет массовый выпуск продуктов на дотнете они доведут джит и пре джит до уровня своих С++-ных компиляторов (которые у них одни из самых лучших).

E>Зато питон гибче и лаконичнее.


Ну, да экономим на объявлениях типов, перменных, и т.п. В итоге получаем багодром. Гибкость должна иметь разумные пределы. Как и контроль. Баланс, вот что важно. Нужна и скорость кодирования, и скорость получаемого кода, и гибкость, и контроль. Собственно именно разумное сочетание ингридиенов и порождает в итоге конечный продукт.

Надо признать, что питон тоже делает шаги в пред. Как я понял его создатили уже избавились от маразматичного отсуствия вложенных уровней видимости. Осталось выбросить статические параметры, добавять обязательное объявление переменных, типизацию, улучшить ООП, ублрать некторые виды неявных приведений и глядишь получится универсальный язык общего применения поддерживающий множество парадигм. Думаю, такой бы язык затмил бы все на своем пути (особенно если при все при этом его компиляторы порождали бы шустрый код). Но это мечта об идиале. А он, как известно, не достижим.

E> Плюс у него есть много других преимуществ (встроенные возможности АОП, например).


Вот об этом интересно было бы послешать по подробнее.

E>Но только какое отношение преимущество шарпа в скорости имеет к заявленным тобой "компонентным возможностям"? Имхо, второстепенное.


Гы. А кому нужны игрушки? Если собранное из компонентов ПО рассыпится или будет напоминать пошаговую стратегию, то пользователь пошлет такой софт к черту и будет пользоваться глючным С++-ным.

E>ЗЫЖ На хочется в очередной раз начинать на этом форуме холивар Static vs. Dynamic.


Да уж. Не стоит. Практика давно показала что они явно не в пользу динамиков.

E>_vovin, в свое время, довольно хорошо про это написал тут. Вряд ли я смогу добавить что-то принципильно новое. А даже если и смогу, тебя всё равно не переубедить, это общеизвестно


А не надо меня убеждать. Ты факты приводи. Пока что скриптовые языки живут в нише "веб-страничек по демпинговым ценам". А за типизированные платят нехилые деньги. Причем спрос на программистов знающих С++, Дельфи, Шарп, Яву намного больше чем предложение. Почти весь коммерческий софт написан на этих языках. Скрпты там в роли скриптов только и присуствуют. Ну, а зачем нужны скрпты если есть языки мало им в чем уступающие, но при этом не скрипты?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Oberon?
От: Зверёк Харьковский  
Дата: 24.10.04 12:40
Оценка:
Влад, я тут тебе спаслание написал, а ты не видишь
http://rsdn.ru/Forum/Message.aspx?mid=865856&amp;only=1
Автор: Зверёк Харьковский
Дата: 24.10.04
FAQ — це мiй ай-кью!
Re[3]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.10.04 13:15
Оценка: +2
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Имхо, ты везде приводишь более-менее верные и логичные аргументы, но не прав в главной своей мысли: "Все пишут на Яве и Шарпе, поэтому учить больше ничего не надо".


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

Более того. Я вот с удовольствием познакомился с Питомном. В отличии от того же СмолТока или Окамла он на меня произвел очень хорошее впечатление (хотя и без огорчений не обошлось). Интересный язык, хорошо поддерживающий разные парадигмы. Если бы не его наплевательство на типы и несколько странное видение ООП, я бы пожалуй согласился с тем, что этот язык был бы очень хорошим кандидатом на превый язык программиста.

Однако я совершенно не понимаю зачем начинать учить детей с экзотики вроде СмолТока или с мертвячины вроде Оберона. Если человеку будет интересно, он этот Оберон и сам выучит. Ну, а не хватит времени или усидчивости, так и фиг с ним. А так получится, что человек выучит оберон, прийдет на работу, а там: С++, Ява, Дельфи, Шарп и т.п. Хочешь не хочешь, а прийдется переучиваться. Причем именно переучиваться, так как Вирт принципиально навязывает свои "привычки". Даже в Дельфи и Васике появился оператор "ретон". А у Вирта свой взгляд на мир. Он учит if-ы вкладывать. Причем начиная учить детей на Обероне им в первую очередь навязывают стиль, а не объясняют принципы построения грамотного кода. В итоге получим зазубрышей резко отвергающих то все промышленные языки и не знакомых банальными понятиями вроде абстракции, наследования, полиморфизма.

ЗХ>Я считаю, что изучение других языков программирования идет не в минус (забиваем голову ненужной информацией), а в плюс. И не потому, что СмолТолк кому-то может пригодиться (ой, сумлеваюсь), а по очень простой причине: расширение кругозора. Просто понять, что "и такое бывает". Подцепить полезный метод или идею. В конце концов (в парадигме начального вопроса Валерия Викторовича) — просто осознать, "что не в любом языке программирования есть фигурные скобки".


Согласен. Но пусть это будет факультативной задачей. А в качестве первого языка пусть будет нечто хорошо спроектированное, но промышленное.

ЗХ>Возьмем, например, меня .

ЗХ>В контексте давнего спора про то, какой язык кому нравится, могу слегка скорректировать свое тогдашнее мнение: "я люблю С++ и пока это возможно, буду писать только на нем", но сейчас собираюсь покупать Рихтера про Шарп. Не потому, что хочу на него перейти — интересно, что нового, чем он отличается; как нужно "думать на Шарпе". А и кроме того, книжки, которые валяются на винте, и которые я уже изучил или собираюсь в ближайшем будушем, посвящены языкам: Ada, Assembler, Awk, C--, C++, C#, Delphi, Eiffel, Euphoria, Forth, Go!, Haskell, Java, Lisp, OCaml, Oz, Perl, PHP, Prolog, Python, Refal, Small, Smalltalk, Tcl, VB.

Здорово. На винтах у меня правда тоже валяется черти что. Но о некоторых языках я даже не слышал. Например, что такое Refal и Go! я не знаю.

Кстати, очень хороший списак. Как по твоему Оберон и СмолТок заслуживают больщего внимания чем все перечисленные тобой тут языки?

Вот по-моему нет. Вот я и предлагая в качестве первого языка выбрать один из языков мэйнстрима, а потом уже приступать к изучению всего остального. Я даже считаю, что здорово было бы изучать параллельно языки имеющие разные парадигмы. Тогда возможно было бы можно избежать ломки понимания.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Oberon?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.10.04 13:29
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Влад, я тут тебе спаслание написал, а ты не видишь

ЗХ>http://rsdn.ru/Forum/Message.aspx?mid=865856&amp;only=1
Автор: Зверёк Харьковский
Дата: 24.10.04


Ну, я же не всевидящий. А вообще, пора завязывать на сегодня. И так пол дня убил на философию.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Мэйнстрим vs. Самосовершенствование :)))
От: prVovik Россия  
Дата: 24.10.04 14:00
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Однако я совершенно не понимаю зачем начинать учить детей с экзотики вроде СмолТока или с мертвячины вроде Оберона.

Думаю, что основной посыл был не в том, чтомы научить студентов какому-то языку программирования, а в том, чтобы учить их программированию вообще (т.е. алгоритмам), причем без жесткой привязки к конкретному языку. Понятно, что совсем без привязки не обойтись, и какой-то конкрентый язык придется выбрать (может даже не один). Но учитывая то, что мэйнстримные языки всеравно будут изучаться, возможно, имеет смысл выбрать в качестве "алгоритмического языка" некий академический язык с налетом фундаментальности, даже если он не обладает выраженной практической применимостью (даже хорошо, если так). Это отнюдь не подразумевает отказ от мэйнстримных языков (они всеравно будут изучены), но, зато, позволит студентам мыслить с помощью более высокоуровневых абстракций, а не в терминах синтаксиса единственного языка, применяемого на протяжении всей их программерской жизни . Тем более, что этот период начального обучения программированию будет проходить не долго и уже, к примеру, на втором курсе можно переходить к мэйнстриму.


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

Проблема мэйнстрима в том, что он все время меняется. И важно сделать так, чтобы студенты не зацикливались на нем. А если вдалбливать мэйнстриме с "самого раннего детства", то, возможно, студент и зациклится. Хотя,

P.S.: разговаривать мы тут можем сколько угодно, но проблема в том, что наш разговор похож на обсуждение красоты заката среди слепых. Выбирать язык для начального обучения программированию должен профессиональный преподаватель с хорошим опытом преподавания. Ему виднее.
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Re[4]: Мэйнстрим vs. Самосовершенствование :)))
От: Зверёк Харьковский  
Дата: 24.10.04 14:28
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Зверёк Харьковский, Вы писали:


ЗХ>>Имхо, ты везде приводишь более-менее верные и логичные аргументы, но не прав в главной своей мысли: "Все пишут на Яве и Шарпе, поэтому учить больше ничего не надо".


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



VD>Более того. Я вот с удовольствием познакомился с Питомном. В отличии от того же СмолТока или Окамла он на меня произвел очень хорошее впечатление (хотя и без огорчений не обошлось). Интересный язык, хорошо поддерживающий разные парадигмы. Если бы не его наплевательство на типы и несколько странное видение ООП, я бы пожалуй согласился с тем, что этот язык был бы очень хорошим кандидатом на превый язык программиста.


VD>Однако я совершенно не понимаю зачем начинать учить детей с экзотики вроде СмолТока или с мертвячины вроде Оберона.

Тут, конечно, ВВ виднее, я ж не преподаватель...
Но в свое время Паскаль и был языком "для учебы" == идеальная чистота концепции + полная непригодность для промышленного использования.
То есть я, кажется, повторяю мысль prVovik в этой же ветке
УАЯ кто-нить помнит? Условный Алгоритмический Язык....

VD>Причем начиная учить детей на Обероне им в первую очередь навязывают стиль, а не объясняют принципы построения грамотного кода.

Сугубый имх: место стройного академического языка — там же, где помянутого мной УАЯ: объяснить человеку, только вчера увидевшему компьютер, что такое условие, цикл, подпрограмма, переменная etc.
При обучении проектированию — уже надо знать "нормальный язык".

ЗХ>>Я считаю, что изучение других языков программирования идет не в минус (забиваем голову ненужной информацией), а в плюс. И не потому, что СмолТолк кому-то может пригодиться (ой, сумлеваюсь), а по очень простой причине: расширение кругозора. Просто понять, что "и такое бывает". Подцепить полезный метод или идею. В конце концов (в парадигме начального вопроса Валерия Викторовича) — просто осознать, "что не в любом языке программирования есть фигурные скобки".


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

См. выше

ЗХ>>Возьмем, например, меня .

ЗХ>>В контексте давнего спора про то, какой язык кому нравится, могу слегка скорректировать свое тогдашнее мнение: "я люблю С++ и пока это возможно, буду писать только на нем", но сейчас собираюсь покупать Рихтера про Шарп. Не потому, что хочу на него перейти — интересно, что нового, чем он отличается; как нужно "думать на Шарпе". А и кроме того, книжки, которые валяются на винте, и которые я уже изучил или собираюсь в ближайшем будушем, посвящены языкам: Ada, Assembler, Awk, C--, C++, C#, Delphi, Eiffel, Euphoria, Forth, Go!, Haskell, Java, Lisp, OCaml, Oz, Perl, PHP, Prolog, Python, Refal, Small, Smalltalk, Tcl, VB.

VD>Здорово. На винтах у меня правда тоже валяется черти что. Но о некоторых языках я даже не слышал. Например, что такое Refal и Go! я не знаю.


Рефал сделали русские. Это, вроде как, функциональный язык...

Рефал — язык манипулирования символьными объектами: текстами, формулами, программами и т.п. Программа на Рефале состоит из функций, которые могут определяться друг через друга, т.е. рекурсивно. Отсюда и название: АЛгоритмический язык РЕкурсивных Функций.
Язык Рефал был создан В. Турчиным [Тур 66] в качестве метаязыка для описания семантики других языков. Впоследствии, в результате появления достаточно эффективных реализаций на ЭВМ он стал находить практическое использование в качестве языка программирования.


Go! — язык, заточенный под программирование агентов.


VD>Как по твоему Оберон и СмолТок заслуживают больщего внимания чем все перечисленные тобой тут языки?

СмолТок — воистину. Именно за счет того, что сильно отличается от всего остального. Просто для раздвижения, так скзть, горизонтов. Но учить его первым — по-моему, искалечить восприятие.
Оберон (пока Губанов не слышит) — полнейшее, на мой вкус, занудство. Его изучение как первого языка еще может быть оправдано теми факторами, о которых я уже сказал. Как второго (третьего...) не даст в смысле мировоззрения абсолютно ничего.
Сугубая, разумеется, имха.
FAQ — це мiй ай-кью!
Re[18]: Oberon?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.10.04 14:33
Оценка: +1
Здравствуйте, eugals, Вы писали:

E>Зато питон гибче и лаконичнее. Плюс у него есть много других преимуществ (встроенные возможности АОП, например).


В дотнет тоже есть встроенный АОП — Transparent Proxy. Знаешь в чем проблема? В производительности этого решения.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
AVK Blog
Re[19]: Oberon?
От: eugals Россия  
Дата: 24.10.04 18:01
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD> С твоими любимыми сообщениями большое приложение рассыпится от рантаймных багов.

Пока ещё у меня ни одно не "рассыпалось".

VD>Забавно так же отсутствие модификаторов доступа (видимости). Все паблик, и все виртуальное. Во, блин, решение. Ни надежности, ни скорости.

В питоне есть несколько более или менее эффективных способов "прятать" переменные.
Фанаты приватности могут спать спокойно.
Естественно всё виртуальное, раз язык динамический. Ты в каждом абзаце про это напоминаешь .

E>> Под питон еть порт всех популярных оконных (и вообще, компонентных) библиотек/технологий: PyQT, PythonNet, PyCOM, PyXPCOM, PyVCL...

VD>Во-во. Порт недо-технологий перехивших свой век.
Ты сказал, что в питоне нет дизайнеров компонентов. Я ответил, что есть — в тех самых компонентных технологиях PyQT, PyCOM-е и т.д.
Что же касается утверждения, что QT и .NET "пережили свой век", то тебе конечно видней, но меня лично и такое старьё устраивает пока

E>>Вот я, например, одним из таких приложений сейчас занимаюсь
Автор: eugals
Дата: 04.08.04

VD>Забавно. Ну, значит должен понимать сколько кода нуно докрутить к чистому Питону, чтобы с ним работать в компонентном стиле.
Не много. В том и прелесть питона, что в нем такие "докручивания" делаются на раз.

VD>Еще раз. Прозрачность должна еще должна быть зачем-то нужна. Если я получаю в 10 раз блее медленное решение, то уж лучше я обойдусь менее прозрачным.

Не в десять.
Тут недавно пробегало сравнение реализации решета эратосфена на Clean-е и C++.
Вот пример на питоне:
from time  import time
from array import array

def test( size):
    arr = array( "b", "\1" * size)
    arr[ 0] = 0
    for i, val in enumerate( arr):
        if val:
            for j in xrange( i + i, size, i):
                arr[ j] = 0
    arr[ 0] = 1
        
tm = time()
test( 100000000)
tm = time() - tm
print tm

Разница с вариантам WolfHound-а у меня была примерно в 3 раза.
Вполне терпимо, для интерпретатора. Наверное можно было бы сократить отставание до двух или даже полуторакратного, если слегка подправить питоновские библиотеки array и itertools. В принципе, ничто не мешает мне, при необходимости, ввести PEP (Python Enchancement Proposal) на этот счет — отцы питона вполне либеральны в отношении таких предложений.
Хотя решето эратосфена, мягко говоря, не самая типичная задача. В GUI, например, всё равно все события через очередь окна пропускаются, питон здесь не будет узким местом (знаю — пробовал).
Вообще, такие сверхтребовательные к ресурсам алгоритмы составляют всё меньший и меньший процент от текущих проблем.
Если мне нужна быстрая метематическая библиотека, то я не буду писать на питоне или шарпе свою, а возьму интеловскую MKL. Нужен универсальный парсер — ANTLR или Бизон или Кока, твой любимый. XML — expat или xerces-c. 3D — OpenGL и т.д.

E>> Плюс удобное Python-Си апи, А С(++), несмотря на майкрософтовский прессрелизы, всё ещё главный мировой язык для разработки библиотек.

VD>Да? И какие ты библиотеки на С++ знаешь?
Да любые необходимые. Парсеры, Средства доступа к БД, Графические библиотеки, Всякие сетевые клиенты/серверы...

VD> А на счет удобства. Что может быть удбонее чем просто использование в одном проекте длл-ек написанных на разных языках?

Вот именно. В конце концов, на мсиле свет клином не сошелся. Нейтив-код это такой же универсальный язык. Более низкоуровневый, ну и фиг с ним, работает ведь.

VD>>>В общем, возможность манимулирования не кодом, а готовыми бинарными модулями.

E>>Ну, в питоне свой формат прекомпилированных файлов. Вполне себе бинарные модули. Не хуже мсильных сборок.
VD>На склько я знаю каждая версия Питона имеет отличный формат и по этому бинарниками никто не поьзуется.
Это да. Не то чтобы совсем уж несовместимы, но лучше пикод от разных версий не использовать . Хотя не знаю, может в 2.4 по этому поводу что-нибудь уже и придумали
VD> Более того они вроде не обязательны. Не создался и ладно...
Не. Если нужен — создастся.

VD>Дык она даже не ключевая. Она базовая предпосылка. Т.е. дивиз такой, просто, просто насколько это можно, но не более просто чем нужно для получения производительного кода.

Само собой. Если бы питон не устраивал нас по производительности, мы бы его не использовали. Устраивает.

E>>Здесь да, спорить бессмысленно — шарп пока быстрее.

VD>Покая? Шарпу 2 года. И с каждым годом он становится все быстрее и быстрее. Думаю, ко времени когда МС начнет массовый выпуск продуктов на дотнете они доведут джит и пре джит до уровня своих С++-ных компиляторов (которые у них одни из самых лучших).
Ну догонит он, а дальше что? Правильно — упрется в железо и остановится.
А скорость питона растет от версии к версии. Не так быстро как хотелось бы, но растет ведь. И потолок тот же — железо.

E>>Зато питон гибче и лаконичнее.

VD>Ну, да экономим на объявлениях типов, перменных, и т.п. В итоге получаем багодром. Гибкость должна иметь разумные пределы. Как и контроль. Баланс, вот что важно. Нужна и скорость кодирования, и скорость получаемого кода, и гибкость, и контроль. Собственно именно разумное сочетание ингридиенов и порождает в итоге конечный продукт.
Ну, тут не поспоришь

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

VD>Осталось выбросить статические параметры,
Это что?
VD>добавять обязательное объявление переменных
Обязательное не нужно. Опциональное — может быть. Чтобы можно было оптимизнуть ( или "констрейнтнуть") "по месту".
VD>Думаю, такой бы язык затмил бы все на своем пути (особенно если при все при этом его компиляторы порождали бы шустрый код). Но это мечта об идиале. А он, как известно, не достижим.
Ну вот, а как же шарп???

E>> Плюс у него есть много других преимуществ (встроенные возможности АОП, например).

VD>Вот об этом интересно было бы послешать по подробнее.
Почитай про метаклассы.
Если вкратце, то вот пример, как можно единообразно сделать журналирование вызовов любых методов конкретного класса, а также всех его наследников:
def createLoggingProxyFor( func):
    def logging_proxy( *args, **kwargs):
        func( *args, **kwargs)
        print "%s called" % func
    print "replacing %s by %s" % ( func, logging_proxy)
    return logging_proxy

class LoggingMetaClass( type):
    """ Метакласс, создающий журналирующую обертку вокруг всех методов своих классов
    """
    def __init__( cls, name, bases, dct):
        type.__init__( cls, name, bases, dct)
        for name, val in dct.iteritems():
            if callable( val) and val != LoggingMetaClass:
                setattr( cls, name, createLoggingProxyFor( val))

class Test( object):
    __metaclass__ = LoggingMetaClass
    
    def foo( self):
        print "foo"

    def bar( self):
        print "bar"

print "starting test"
t = Test()
print "calling foo"
t.foo()
print "calling bar"
t.bar()

Кстати, с помошью метаклассов, можно прикрутить к методам и проверку типов передаваемых в них параметров (и вообще, пред- и постусловий).
Особенно после того, как в Python 2.4 появились атрибуты (декораторы), навроде шарповских (вообще, они и раньше типа были, но не такие удобные).

E>>Но только какое отношение преимущество шарпа в скорости имеет к заявленным тобой "компонентным возможностям"? Имхо, второстепенное.

VD>Гы. А кому нужны игрушки? Если собранное из компонентов ПО рассыпится или будет напоминать пошаговую стратегию, то пользователь пошлет такой софт к черту и будет пользоваться глючным С++-ным.
Не рассыпается. Стратегию не напоминает. Пользователи не посылают.
... << RSDN@Home 1.1.4 @@subversion >>
Re[11]: Oberon???????????????????????????????????
От: eugals Россия  
Дата: 25.10.04 06:40
Оценка: 30 (2)
Здравствуйте, VladD2, Вы писали:

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

Это да . К счастью, у _vovin-а на сайте есть пара интересных howto по Dolphin-у: Dolphin Smalltalk, Part I и Dolphin Smalltalk, Part I.
Очень помогают от барановоротного эффекта
... << RSDN@Home 1.1.4 beta 2 >>
Re[6]: Oberon???????????????????????????????????
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 25.10.04 07:58
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>...При этом Оберон не имеет какх-то существенных приемуществ при обучении...


А вот, компетентные в этом вопросе люди утверждают обратное. Ссылки я уже приводил.
Re[4]: Мэйнстрим vs. Самосовершенствование :)))
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 25.10.04 08:07
Оценка: -2
Здравствуйте, VladD2, Вы писали:

VD>.....появился оператор "ретон". А у Вирта свой взгляд на мир. Он учит if-ы вкладывать.


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


VD>.....Причем начиная учить детей на Обероне им в первую очередь навязывают стиль, а не объясняют принципы построения грамотного кода....


А вот компетентные в этом вопросе люди утверждают обратное. Ссылки я уже неоднократно приводил.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.