Re[5]: Мои мысли по теме Статика sv. Динамика
От: FR  
Дата: 11.11.06 06:47
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


GZ>>>Но частично оно ведь может доказать неправильность программы?

FR>>Что оно? Статическая типизация?
GZ>Да.

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

FR>>>>И наооборот для алгоритмов с жесткими условиями необходимы обширные тесты, которые нивелируют типизацию.

GZ>>>В честь чего? По крайней мере доказательство выводимости типов можно не делать. В то же время доказательство вывода типов в динамике можно и нужно делать.
FR>>Зачем это делать, если функциональность полностью покрыта тестами?
GZ>Не все алгоритмы можно покрыть тестами. Ведь даже проверка граничных условий не дает полной гарантии правельности результата. Нельзя полностью проверить например компилятор поскольку входных параметров может быть слишком большое количество. Вобщем ситуация со стат. и дин. языками тут не сильно различается.

Так я про-то же оба не дают гарантий.

FR>>>>СТЯП позволяют в runtime подменить метод у класса?

FR>>А при чем тут полиморфизм?
GZ>А это и есть полиморфизм. То бишь позднее связывание. Кроме того, есть еще делегаты, что практически аналогично. Может быть ты хотел сказать добавить новый метод?

Без разницы, полиморфизм слишком жестко ограничен.

FR>>JScript.Net не СТЯП.

GZ>Самое интересное что как раз статически компилируемый. При этом он не потерял ни одно из свойств динамического языка JavaScript.(кроме конечно дин. компиляции). Прототипирование там есть.

И что? Гибридных языков и без него прилично, например диалекты лиспа или Dylan.

FR>>>>Питон и Руби точно не проигрывают по выразительности Эрлангу, разве для некторых специфичных задач, в более общих задачах эрланг сам им уступает. Nemerle конечно по выразительности во многом лучше, но по краткости до J ему как пешком до пекина

GZ>>>Занятно. Это ты доказал утверждение Влада.
FR>>Какое?
GZ>О том что выразительность зависит от самого языка а не от того, какой он — динамически или статически компилируемый.

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

FR>>В С++ не бесплатное, наооборот во многом неоправданно слишком усложненное. Под ценой имеется в виду цена для программиста а не для производительности программы.

GZ>В данном случае ведь тоже не все однозначно. Утиная типизация хороша только по месту. Иначе получаешь больше вреда чем пользы.

Это да, как и с любыми другими возможностями.

FR>>>>7. Динамика гораздо удобнее как склеевающий и настроечый язык, особенно для непрофессионалов.

GZ>>>Почти соглашусь но одно но. Выражение особенно для непрофессионалов в корне неверное.
FR>>Правильнее будет для непрофессиональных программистов.
FR>>Он не новичок, а скажем так скорее не программист а настройщик. И чем проще язык освоить и использовать тем для него лучше.
GZ>Тогда лучше сказать для непрофессиональных небольших программ. Кстати большинство таких языков было сделано именно с подобной целью.

Ну так это и есть скриптование. Но это только одно из возможных применений динамики.

GZ>Угадай, что мне сказал строготипизированный язык python когда я выполнил fib("2000")? Да ничего, о просто ушел в бесконечный цикл.


Это да прокол, операторы сравнения надо менять. Одна из неприятных вещей которые я считаю багом в дизайне языка, оператор сравнения должен уметь сравнивать любые объекты, обосновывается тем что списки могут содержать любой объект и по умолчанию эти объекты должны уметь сравниватся.
Re[6]: Мои мысли по теме Статика sv. Динамика
От: Андрей Хропов Россия  
Дата: 11.11.06 11:08
Оценка: +1
Здравствуйте, FR, Вы писали:

GZ>>>>Но частично оно ведь может доказать неправильность программы?

FR>>>Что оно? Статическая типизация?
GZ>>Да.

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


Она не мешает, она помогает.
А если надо что-то обходить то это и должно быть сложно, чтобы не хотелось это делать ибо это потенциальный источник багов.

Для меня программа с типами выглядит более понятной, особенно если нормальные наименования для переменных.
В динамике все просто пока простые типы данных — строки, числа. А если структуры или классы то уже все становится запутанным.

FR>>>Зачем это делать, если функциональность полностью покрыта тестами?

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

FR>Так я про-то же оба не дают гарантий.


Re[49]: JRuby, RubyCLR, IronPython — зачем?
Автор: Андрей Хропов
Дата: 08.11.06
.

FR>>>>>СТЯП позволяют в runtime подменить метод у класса?

FR>>>А при чем тут полиморфизм?
GZ>>А это и есть полиморфизм. То бишь позднее связывание. Кроме того, есть еще делегаты, что практически аналогично. Может быть ты хотел сказать добавить новый метод?

FR>Без разницы, полиморфизм слишком жестко ограничен.


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

FR>>>JScript.Net не СТЯП.

GZ>>Самое интересное что как раз статически компилируемый. При этом он не потерял ни одно из свойств динамического языка JavaScript.(кроме конечно дин. компиляции). Прототипирование там есть.

FR>И что? Гибридных языков и без него прилично, например диалекты лиспа или Dylan.


Ну и хорошо . Я за такие языки. Да и очевидно за ними будущее.

FR>>>>>Питон и Руби точно не проигрывают по выразительности Эрлангу, разве для некторых специфичных задач, в более общих задачах эрланг сам им уступает. Nemerle конечно по выразительности во многом лучше, но по краткости до J ему как пешком до пекина

GZ>>>>Занятно. Это ты доказал утверждение Влада.
FR>>>Какое?
GZ>>О том что выразительность зависит от самого языка а не от того, какой он — динамически или статически компилируемый.

FR>Нет Влад удтверждал что статические языки более выразительные.


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

GZ>>В данном случае ведь тоже не все однозначно. Утиная типизация хороша только по месту. Иначе получаешь больше вреда чем пользы.


FR>Это да, как и с любыми другими возможностями.


Вот в том то и дело что в динамике она всегда "включена".
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Мои мысли по теме Статика sv. Динамика
От: FR  
Дата: 11.11.06 11:50
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

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


GZ>>>>>Но частично оно ведь может доказать неправильность программы?

FR>>>>Что оно? Статическая типизация?
GZ>>>Да.

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


АХ>Она не мешает, она помогает.


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

АХ> А если надо что-то обходить то это и должно быть сложно, чтобы не хотелось это делать ибо это потенциальный источник багов.


В программировании куда ни ткни везде есть потенциальные источники багов

АХ>Для меня программа с типами выглядит более понятной, особенно если нормальные наименования для переменных.


Это вопрос привычки и личных предпочтений.
Опять же есть места где на самом деле аннотация типов полезна и улучшает читабельность(например публичные интерфейсы) и есть где она ничего кроме бесполезного шума не вносит (большинство локального кода)

АХ>В динамике все просто пока простые типы данных — строки, числа. А если структуры или классы то уже все становится запутанным.


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

FR>>Так я про-то же оба не дают гарантий.


АХ>Re[49]: JRuby, RubyCLR, IronPython &mdash; зачем?
Автор: Андрей Хропов
Дата: 08.11.06
.


??

FR>>>>>>СТЯП позволяют в runtime подменить метод у класса?

FR>>>>А при чем тут полиморфизм?
GZ>>>А это и есть полиморфизм. То бишь позднее связывание. Кроме того, есть еще делегаты, что практически аналогично. Может быть ты хотел сказать добавить новый метод?

FR>>Без разницы, полиморфизм слишком жестко ограничен.


АХ>В смысле? Полиморфизм — это когда одинаково написанный код работает по-разному в зависимости от того какие типы используются.

АХ>А что не ограничено?

утиная типизация в динамических языках.

FR>>>>JScript.Net не СТЯП.

GZ>>>Самое интересное что как раз статически компилируемый. При этом он не потерял ни одно из свойств динамического языка JavaScript.(кроме конечно дин. компиляции). Прототипирование там есть.

FR>>И что? Гибридных языков и без него прилично, например диалекты лиспа или Dylan.


АХ>Ну и хорошо . Я за такие языки. Да и очевидно за ними будущее.


Так и я не против

FR>>>>>>Питон и Руби точно не проигрывают по выразительности Эрлангу, разве для некторых специфичных задач, в более общих задачах эрланг сам им уступает. Nemerle конечно по выразительности во многом лучше, но по краткости до J ему как пешком до пекина

GZ>>>>>Занятно. Это ты доказал утверждение Влада.
FR>>>>Какое?
GZ>>>О том что выразительность зависит от самого языка а не от того, какой он — динамически или статически компилируемый.

FR>>Нет Влад удтверждал что статические языки более выразительные.


АХ>Нет, Влад как раз утверждал что они могут быть не менее выразительными чем динамические.


Может его самого спросим?

АХ>А если выразительность не ухудшается, но имеем дополнительные статические проверки и большую производительность, то зачем нам динамика.


Так вам никто ни навязывает, не нравится не ешьте.
Это же только у поклоников Немерле есть серебряная пуля, остальные не претендуют
Re[8]: Мои мысли по теме Статика sv. Динамика
От: Андрей Хропов Россия  
Дата: 11.11.06 13:02
Оценка: +1
Здравствуйте, FR, Вы писали:

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


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


GZ>>>>>>Но частично оно ведь может доказать неправильность программы?

FR>>>>>Что оно? Статическая типизация?
GZ>>>>Да.

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


АХ>>Она не мешает, она помогает.


FR>Зависит от ситуации.

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

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

АХ>> А если надо что-то обходить то это и должно быть сложно, чтобы не хотелось это делать ибо это потенциальный источник багов.


FR>В программировании куда ни ткни везде есть потенциальные источники багов


Ну вот языки и развиваются в том направлении чтобы уменьшить количество и качество этих источников.

АХ>>Для меня программа с типами выглядит более понятной, особенно если нормальные наименования для переменных.


FR>Это вопрос привычки и личных предпочтений.

FR>Опять же есть места где на самом деле аннотация типов полезна и улучшает читабельность(например публичные интерфейсы) и есть где она ничего кроме бесполезного шума не вносит (большинство локального кода)

Авторы Немерле, Скалы и я с тобой согласны .

АХ>>В динамике все просто пока простые типы данных — строки, числа. А если структуры или классы то уже все становится запутанным.


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


Я не про это — я про понимание сигнатур:

def print_name(name,surname): # понятно, что скорее всего name и surname - это строки
 ...
 
def post_mail(address,message_body,pop3_server): # непонятно в каком формате address, body и server
    ...                                               
    # то есть конечно наверное где-то эти структуры описаны, но какие конкретно сразу непонятно


FR>>>Так я про-то же оба не дают гарантий.


АХ>>Re[49]: JRuby, RubyCLR, IronPython &mdash; зачем?
Автор: Андрей Хропов
Дата: 08.11.06
.


FR>??


Advocates of strongly typed languages such as ML and Haskell have suggested that almost all bugs can be considered type errors, if the types used in a program are sufficiently well declared by the programmer or inferred by the compiler

(и ссылаются на статью ссылаются на статью Dependent Types in Practical Programming).

На самом деле вот простой пример:

int ComputeTime(int hours, int minutes, int seconds)
{
    return ((hours*60 + minutes)*60+seconds);
}

int main()
{
    int sec = ComputeTime(15,5,45);  // нормально
    int min = ComputeTime(15,5,45);  // перепутали что считает в минутах а не секундах - баг!
    int sec1 = ComputeTime(45,5,15); // перепутали местами часы и секунды - баг!
    int sec2 = ComputeTime(45,5,15); // при этом часы > 24 - но компилятор пропустил
    return 0;
}


Другой вариант
#include <cassert>

typedef unsigned int uint;

template<uint Bound> class BoundedVal
{
        uint _val;
    public:        
        BoundedVal(uint val) : _val(val) { assert(_val < Bound); }
        uint operator()(){ return _val; }
};

namespace Time
{
    class Seconds : public BoundedVal<60>
    {
    public: Seconds(uint sec) : BoundedVal<60>(sec) {}
    };
    class Minutes : public BoundedVal<60>
    {
    public: Minutes(uint min) : BoundedVal<60>(min) {}
    };
  class Hours : public BoundedVal<24>
    {
    public: Hours(uint hrs) : BoundedVal<24>(hrs) {}
    };
}

Time::Seconds ComputeTime(Time::Hours hours, Time::Minutes minutes, Time::Seconds seconds)
{
    return Time::Seconds((hours()*60 + minutes())*60+seconds());
}

int main()
{
  using namespace Time;
  Seconds sec = ComputeTime( Hours(15), Minutes(5), Seconds(45) ); //ок
  //Minutes min = ComputeTime( Hours(15), Minutes(5), Seconds(45) ); //ошибка компиляции - несоответствие результата
  //Seconds sec1 = ComputeTime(Seconds(45),Minutes(5),Hours(15) ); // ошибка компиляции - несоответствие типов параметров
  Seconds sec2 = ComputeTime(Hours(45),Minutes(5),Seconds(15) ); // 1) вряд ли кто-то напишет Hours(45)
                                                                                                                             // 2) ошибка в рантайме - часы > 24.
  return 0;
}


Да, код занял больше места (но это конкретно в C++!), но зато мы получили более безопасное решение.

FR>>>>>>>СТЯП позволяют в runtime подменить метод у класса?

FR>>>>>А при чем тут полиморфизм?
GZ>>>>А это и есть полиморфизм. То бишь позднее связывание. Кроме того, есть еще делегаты, что практически аналогично. Может быть ты хотел сказать добавить новый метод?

FR>>>Без разницы, полиморфизм слишком жестко ограничен.


АХ>>В смысле? Полиморфизм — это когда одинаково написанный код работает по-разному в зависимости от того какие типы используются.

АХ>>А что не ограничено?

FR>утиная типизация в динамических языках.


Так это частный случай полиморфизма: здесь.

FR>>>Нет Влад удтверждал что статические языки более выразительные.


АХ>>Нет, Влад как раз утверждал что они могут быть не менее выразительными чем динамические.


FR>Может его самого спросим?


4. Код на ДТЯП (динамически типизированные языки программирования) меньше и его легче держать в голове. Это откровенная лож. Но эта лож пожалуй чаще всего повторяется поклонниками ДТЯП. А чтобы эта лож не выглядила очень уж явно она всегда преподносится на фоне ЯП вроде С и С++ чья выразительность уже давно оставляет желать лучшего. Правда же заключается в том, что выразительность языка (а именно она определяет сколько кода нужно для выражения одной мысли) определяется не типом типизации, а количеством и качеством реализованных в них языковых конструкций (и/или средств расширения языка). Так ДТЯП чаще всего пиаримые на этом форуме — Питон и Руби существенно проигрывают как ДТ Эрлэнгу, так и СТ Nemerle-у просто потому, что в их арсенале нет таких мощных средств как алгебраические типы и сопоставление с образцом.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: Мои мысли по теме Статика sv. Динамика
От: FR  
Дата: 11.11.06 15:08
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

FR>>Зависит от ситуации.

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

АХ>Почему? В OCaml ты всегда не будешь типы указывать.


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

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


Для моих задач питон удобней.

АХ>>> А если надо что-то обходить то это и должно быть сложно, чтобы не хотелось это делать ибо это потенциальный источник багов.



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


АХ>Я не про это — я про понимание сигнатур:


Ну ты вроде говорил про структуры данных
А так конечно надо хоть минимально документировать код.

FR>>??


АХ>

АХ> Advocates of strongly typed languages such as ML and Haskell have suggested that almost all bugs can be considered type errors, if the types used in a program are sufficiently well declared by the programmer or inferred by the compiler

АХ>(и ссылаются на статью ссылаются на статью Dependent Types in Practical Programming).

АХ>На самом деле вот простой пример:


.........

АХ>Да, код занял больше места (но это конкретно в C++!), но зато мы получили более безопасное решение.


Код будет больше не только на C++, но на любом другом языке, ты же вводишь новые сущности, реально это уже совсем другая задача. Тут вопрос в цене если нам нужна большая надежность то придется именно так и писать и плюс еще тестировать, но срок разработки может удлинится (удорожится) в несколько раз. И еще контракты и проверки точно также можно использовать и в динамических языках, конечно контроль будет в run-time но в принципе будет тоже самое (даже этот пример можно почти в 1:1 на питоне переписать).

FR>>утиная типизация в динамических языках.


АХ>Так это частный случай полиморфизма: здесь.


Я понял что выше под полиморфизмом имелись в виду виртуальные функции.
Re[2]: Мои мысли по теме Статика sv. Динамика
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.06 19:51
Оценка:
Здравствуйте, DerBober, Вы писали:

DB>Такие рассуждения явно показывают надуманость гипотизы о существовании идеального языка программирования (ИЯП) в отрыве от приложений.


Я устал повторять, что идиал недостижим, но стремление к нему — это то что делает человека человеком.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Мои мысли по теме Статика sv. Динамика
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.06 19:51
Оценка: :)
Здравствуйте, vdimas, Вы писали:

V>Пока что нет, хотя я не вижу причин, почему бы не сделать подобную поддержку полноценной. Технических препятствий, например, для платформы дотнет и языка C# нет, надо просто потратить на это определенное кол-во времени и ср-в.


По-моему интерактивности более чем достаточно. Конечно есть куда развиваться, но все же, то что есть сейчас меня полностью устраивает.

V>Немного не так.


V>1. В "стандартном режиме" запуск программы всегда предполагает лишь одну точку входа, пожтому "добраться" до тестируемого участка не всегда легко.


Это откровенная не правда. Путей "добраться" до метода тучи. В C# ты можешь тупо вызвать метод из окна Imediate. Кроме тогда всегда можно создать простенькое консольное приложение, кодключить к нему отлаживамую сборку и напрямую вызвать нужные методы.

V>2. Средства, типа NUnit немного помогают, до тех пор, пока кол-во размеченных тестов не переваливает за несколько сотен. Тогда эти ср-ва становятся откровенной обузой при попытке организовать с их помощью интерактивный режим разработки.


Несогласен с этим мнением. Да и это не динамика. Тесты на каждый чих просто не нужны.

V>3. Некоторые классы задач требуют предварительной инициализации окружения. Например у нас сервак "встает" минимум 10-15 сек.


Я конечно вас сочусвтую. Фиговые у вас проектировшики. Но эту проблему вы бы получили и в динамике. Конечно приятно, что пое что можно было бы поправить без перезапуска, но запуск все равно делать пришлось бы. И если у вас на компилируемом языке получается 15 сек., то на скрипте вы получили бы уже минуту и более.

Тут надо думать как сделать подсистемы сервера независимыми. И как ускорить загрузку и инициализацию приложения. Уверен, что это возможно.

V>Повторю, недостаток лишь в текущем качестве популярных инструментов для статических языков на динамических платформах.


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

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


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

V>Я уже высказвал свое ИМХО, что любители динамических языков любят их скорее за своеобразную организацию труда при их использовании. Дайте это же в мир статических языков (типа макроса "late" в N), и все будет в шоколаде.


Незнаю. Я ни разу не использвал late и даже желания не возникало. Согласен, что повышение интерактивности разработки — это хорошо, но считаю, что рассуждения о неинтерактивности текущих версий языков и сред натянутым.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Мои мысли по теме Статика sv. Динамика
От: MikhasSergei Земля  
Дата: 11.11.06 20:22
Оценка: 32 (2) :))
Полушутя, полусерьезно...

Опыт, батенька, и пиар — вот движущий фактор эволюции.
Re[3]: Мои мысли по теме Статика sv. Динамика
От: DerBober США  
Дата: 11.11.06 22:01
Оценка: -1 :))
Здравствуйте, VladD2, Вы писали:

DB>>Такие рассуждения явно показывают надуманость гипотизы о существовании идеального языка программирования (ИЯП) в отрыве от приложений.


VD>Я устал повторять, что идиал недостижим, но стремление к нему — это то что делает человека человеком.


Бобер уже достиг идеала в сфере платиностроения и стал человеком. Формула: ИЯП(б) = C++ + python + shell
Re[9]: Мои мысли по теме Статика sv. Динамика
От: ironwit Украина  
Дата: 14.11.06 06:05
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Также нужно иметь в виду что на моих задачах нужно выжать из железа 90%-100% производительности те питон и тем болие руби идут лесом тк тормоза.

можно ли тихонько на ушко намекнуть на решаемые тобой задачи?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Я не умею быть злым, и не хочу быть добрым.
Re[2]: Мои мысли по теме Статика sv. Динамика
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.11.06 08:28
Оценка: +1 -1
Здравствуйте, MikhasSergei, Вы писали:

MS> Опыт, батенька, и пиар — вот движущий фактор эволюции.


Причем, зачастую, опыт является следствием пиара.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Мои мысли по теме Статика sv. Динамика
От: Lever Россия www.compassplus.ru
Дата: 14.11.06 09:52
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Тема ушла в полнейший аут. Так что лазить по ней нет никакого желания. Если у кого есть желание, то можете выскаться здесь.


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


Хочу тоже добавить несколько суждений.
1.Все это относительно. Если абсолютную статику я худо бедно представляю, и предстаквляю ее необходимость. То необходимость абсолютной динамики не представляю. Хоть что-то похожее мы делали.
2. Если представить программу не как единое целое, а как сокупность частей, а лучше всего совсем не как программу, то в разных частях этого большого нечто, могут уживаться и статика и динамика.
3. Я бы различал создание типов и их использование. И отдельно говорил о статике и о динамике и для того идля другого.
Re[2]: Мои мысли по теме Статика sv. Динамика
От: Кодт Россия  
Дата: 15.11.06 16:20
Оценка: 1 (1)
Здравствуйте, Курилка, Вы писали:

К>А некоторые очень любят REPL, а его на статике врядли получишь


Контрпример: интерпретаторы хаскелла (например, HUGS).

СТ в REPL помогает, отсекая простейшие логические ошибки. В лиспе можно ввести какой-нибудь синтаксически корректный бред, а потом удивляться.
(defun bred1 (x) (+ (car x) x))
(defun bred2 (x) (+ (car x) (cdr x)) %% впрочем, это может быть корректным для cons-пары из двух чисел

А хаскелл сразу надаёт по пальцам.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[3]: Мои мысли по теме Статика sv. Динамика
От: Курилка Россия http://kirya.narod.ru/
Дата: 15.11.06 16:30
Оценка:
Здравствуйте, Кодт, Вы писали:

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


К>>А некоторые очень любят REPL, а его на статике врядли получишь


К>Контрпример: интерпретаторы хаскелла (например, HUGS).


К>СТ в REPL помогает, отсекая простейшие логические ошибки. В лиспе можно ввести какой-нибудь синтаксически корректный бред, а потом удивляться.

К>
К>;(defun bred1 (x) (+ (car x) x))
К>;(defun bred2 (x) (+ (car x) (cdr x)) %% впрочем, это может быть корректным для cons-пары из двух чисел
К>;

К>А хаскелл сразу надаёт по пальцам.

Про "по пальцам" — понятно, но вот достижима ли там искомая гибкость
Есть подозрение (хотя с хагсом игрался очень мало, не специалист), что это будет довольно сложно. Или там "на лету" можно, например, поменять код метода класса? (Хотя вроде классов в хаскеле нет, уже плохо помню )
И что-то не помню, чтобы REPL по отношению к хаскелю применяли. Хотя это, конечно, не показатель.
Re[3]: Мои мысли по теме Статика sv. Динамика
От: Programmierer AG  
Дата: 17.11.06 11:02
Оценка: 11 (1) +1
Кодт wrote:

> Контрпример: интерпретаторы хаскелла (например, HUGS).

>
> СТ в REPL помогает, отсекая простейшие логические ошибки. В лиспе можно ввести какой-нибудь синтаксически корректный бред, а потом удивляться.
>
>; (defun bred1 (x) (+ (car x) x))
>; (defun bred2 (x) (+ (car x) (cdr x)) %% впрочем, это может быть корректным для cons-пары из двух чисел
>;

> А хаскелл сразу надаёт по пальцам.

По пальцам, конечно, надает. Но в целом контрпример слабенький.
Хаскеловские интерпретаторы годятся только для того, чтобы загрузить в
них исходник и поиграться с определенными в нем функциями (что само по
себе неплохо, т.к. избавляет от необходимости писать тестовый код).
Ни Hugs, ни ghci не позволяют вводить определения новых типов. В хугсе
даже новые функции и переменные вводить нельзя, а в ghci для этого
приходится вот так извращаться:
Prelude> x <- return 1 -- вместо x=1
Prelude> twice <- return $ \x -> x*2 -- вместо twice x = x*2

Гораздо лучше с этим у окамла и F#, там интерактивному toplevel'у можно
скормить что угодно. Но и у них есть проблема: lexical scoping. В
интерпретаторе Схемы можно исправить ошибку в коде вспомогательной
функции, и все заработает:
gleb@gleb:~/src/crap> guile
guile> (define (avg x y) (+ x y)) ; черт, забыл поделить на 2!
guile> (define (foo x y u v) (+ (avg x y) (avg u v)))
guile> (foo 1 2 3 4)
10
guile> (define (avg x y) (/ (+ x y) 2))
guile> (foo 1 2 3 4)
5.0

А в интерпретаторе Окамла после переопределения avg функция foo будет
использовать старую версию avg. Что в результате приводит к тому же
сценарию, что и с hugs/ghci: код набираем в емаксе с tuareg-mode, после
каждого изменения — tuareg-eval-buffer (т.е. загружаем весь файл заново
в интерпретатор).
Posted via RSDN NNTP Server 2.0
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.