Прошу прощения за флеймоопасную тему, может настроение просто такое ...
Если посмотреть на ChangeLog языка Scala то количество строк вида Fixed compiler crash просто поражает (только в 2.6.0-RC2 по сравнению с 2.6.0-RC1 было исправлено 20 штук). Вот я и не понимаю: откуда вообще такое количество крэшей?
Ладно бы язык был небезопасный. Так ведь нет, на JVM все, куда уж безопаснее. Да и не чисто императивный это язык, а императивно-функциональный гибрид. Ну т.е. самый писк нонче. Не чета древним C++ам.
И ладно бы один человек Scala занимался, может компилятор -- это сильно сложно для одного человека (хотя глядя на Вальтера Брайта...). Так ведь их же там десять разработчиков.
И ладно бы у них было строгое расписание и дедлайн, который профукать нельзя. Так ведь и этого не видно -- не обозначено у них точных сроков выхода 2.6.0 вообще.
Может у них просто подход к разработке такой -- пусть пользователи тестируют, то что мы не достестировали?
Или это вообще сейчас тенденция такая в софтостроении -- ничего стабильного нет, поскольку оплачивается скорость выхода продукта на рынок, а не его качество?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Или это вообще сейчас тенденция такая в софтостроении -- ничего стабильного нет, поскольку оплачивается скорость выхода продукта на рынок, а не его качество?
Эта тенденция была всегда. Объясняю на пальцах.
Есть программа с двумя элементами. Между ними одна связь. X — Y
Усложним программу, добавив ещё один элемент. Между ними уже будет 3 связи
X — Y
\ /
Z
Добавим ещё один элмемент, ещё один... Количество связей в программе растёт факториально!
При изменении каждого элемента тебе надо проверить все связи, любая может быть нарушена и программа получит ошибку.
Борьба с этой возрастающей сложностью — и есть основная проблема программирования. Именно для её решения выдумывают модульное, объектное программирование и прочие технологии. Они помогают уменьшить скорость роста взаимосвязей, инкапсулируют работу отдельных частей, уменьшают количество взаимосвязей. Но эти приёмы не всесильны. Вместо количества связей между глобальными переменными и функциями — появляются связи между классами. Было 100 элементов (глобальных переменных и функций), стало 10 классов. Код, конечно, стал сложнее и может много больше — в каждом классе у нас по несколько функций и полей. И теперь мы можем делать более сложные программы. И делаем. И получаем программу из 100 классов — и опять она приходит к порогу, за которым её сопровождение становится невозможным.
А ты думаешь, это из-за плохой кармы MS писала Vista 5 лет и потратила 6 миллиардов, реализовав меньше половины обещанных фич? Нет, просто они тоже упёрлись в этот порог. И раньше упирались, когда Windows 1.0 написали — только тогда это был порог сложности технологий того уровня.
ЗЫ Теперь понятно, почему тебе Ruby так понравился... ты просто не писал никогда сложных программ, не участвовал в сложных проектах.
Здравствуйте, eao197, Вы писали:
E>Или это вообще сейчас тенденция такая в софтостроении -- ничего стабильного нет, поскольку оплачивается скорость выхода продукта на рынок, а не его качество?
Угу, это sales-driven development. Сами постоянно с этим сталкиваемся.....
Здравствуйте, eao197, Вы писали:
E>Если посмотреть на ChangeLog языка Scala то количество строк вида Fixed compiler crash просто поражает (только в 2.6.0-RC2 по сравнению с 2.6.0-RC1 было исправлено 20 штук). Вот я и не понимаю: откуда вообще такое количество крэшей?
Вот и я думаю: откуда бы там быть такому количеству крэшей...
Здравствуйте, mkizub, Вы писали:
E>>Или это вообще сейчас тенденция такая в софтостроении -- ничего стабильного нет, поскольку оплачивается скорость выхода продукта на рынок, а не его качество?
M>Эта тенденция была всегда.
Довелось мне в течении тескольких лет использовать Turbo C 2.0 и MultiEdit 6-7. Что-то по моим воспоминаниям не всегда была эта тенденция.
Scala, вероятно, посложнее Turbo C (ой ли). Но уж явно не сложнее MultiEdit-а.
M>ЗЫ Теперь понятно, почему тебе Ruby так понравился... ты просто не писал никогда сложных программ, не участвовал в сложных проектах.
Да, повезло. Продолжаю пребывать в блаженном неведении.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, mkizub, Вы писали:
E>>>Или это вообще сейчас тенденция такая в софтостроении -- ничего стабильного нет, поскольку оплачивается скорость выхода продукта на рынок, а не его качество?
M>>Эта тенденция была всегда.
E>Довелось мне в течении тескольких лет использовать Turbo C 2.0 и MultiEdit 6-7. Что-то по моим воспоминаниям не всегда была эта тенденция.
Ты пользовал Scala и она у тебя на всех этих, отмеченных в ChangeLog, ситуациях падала?
Из тысяч пользователей она падает у одного, он сабмитит ошибку и её правят. Остальные об этой ошибке никогда и не узнают, если не читают ChangeLog.
E>Scala, вероятно, посложнее Turbo C (ой ли). Но уж явно не сложнее MultiEdit-а.
А ты их ChangeLog-и читал? Почитай списки ошибок в стабильных продуктах, будешь сильно удивлён.
Здравствуйте, eao197, Вы писали:
E>Вот я и не понимаю: откуда вообще такое количество крэшей? E>Ладно бы язык был небезопасный.
От плохих программистов? Возможно, ученые, которые её создали, весьма подкованы в теории и создали логичный и целостный язык, но в реализации оказались не очень. Стоит поглядеть её исходный код.
Здравствуйте, eao197, Вы писали:
E>Если посмотреть на ChangeLog языка Scala то количество строк вида Fixed compiler crash просто поражает (только в 2.6.0-RC2 по сравнению с 2.6.0-RC1 было исправлено 20 штук). Вот я и не понимаю: откуда вообще такое количество крэшей? E>Ладно бы язык был небезопасный. Так ведь нет, на JVM все, куда уж безопаснее. Да и не чисто императивный это язык, а императивно-функциональный гибрид. Ну т.е. самый писк нонче. Не чета древним C++ам.
... E>Может у них просто подход к разработке такой -- пусть пользователи тестируют, то что мы не достестировали?
Чего-то не пойму, в чем проблема. До релиза в продукте нашли и исправили некоторое количество ошибок, в чем можно обвинять разработчиков? Отличие безопасного от небезопасного языка тут проявляется понятно где — "крэшем" называют не дамп регистров и не порчу данных, а падение по исключению, ошибки в алгоритмах мейнстримные "безопасные" языки исправлять еще не научились (есть языки побезопаснее — Epigram, Omega, но захотите ли вы на них писать?).
Здравствуйте, palm mute, Вы писали:
E>>Если посмотреть на ChangeLog языка Scala то количество строк вида Fixed compiler crash просто поражает (только в 2.6.0-RC2 по сравнению с 2.6.0-RC1 было исправлено 20 штук). Вот я и не понимаю: откуда вообще такое количество крэшей? E>>Ладно бы язык был небезопасный. Так ведь нет, на JVM все, куда уж безопаснее. Да и не чисто императивный это язык, а императивно-функциональный гибрид. Ну т.е. самый писк нонче. Не чета древним C++ам. PM>... E>>Может у них просто подход к разработке такой -- пусть пользователи тестируют, то что мы не достестировали?
PM>Чего-то не пойму, в чем проблема. До релиза в продукте нашли и исправили некоторое количество ошибок, в чем можно обвинять разработчиков? Отличие безопасного от небезопасного языка тут проявляется понятно где — "крэшем" называют не дамп регистров и не порчу данных, а падение по исключению, ошибки в алгоритмах мейнстримные "безопасные" языки исправлять еще не научились (есть языки побезопаснее — Epigram, Omega, но захотите ли вы на них писать?).
Проблема в том, что существует поверье, мол чем выше язык, тем более сложные задачи он позволяет решать. А более простые задачи позволяет решать проше и быстрее. Так вот, больше всего меня интересует, раз Scala сейчас вбирает в себя все лучшее и работают над ним совсем не глупые люди, почему же у них в ChangeLog-е после первого релиз кандидата (это все-таки не бэта даже, а почти релиз) критические ошибки десятками вылазюют. Не сильно-то, видно, облегчает.
А что не было релиза, так это не показатель -- можно глянуть предыдущие версии, крэшей и там после релизов найти можно порядком.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, mkizub, Вы писали:
E>>>>Или это вообще сейчас тенденция такая в софтостроении -- ничего стабильного нет, поскольку оплачивается скорость выхода продукта на рынок, а не его качество?
M>>>Эта тенденция была всегда.
E>>Довелось мне в течении тескольких лет использовать Turbo C 2.0 и MultiEdit 6-7. Что-то по моим воспоминаниям не всегда была эта тенденция.
M>Ты пользовал Scala и она у тебя на всех этих, отмеченных в ChangeLog, ситуациях падала? M>Из тысяч пользователей она падает у одного, он сабмитит ошибку и её правят. Остальные об этой ошибке никогда и не узнают, если не читают ChangeLog.
Хоть я и не долго пользовался Scala и на простых примерах, но на баг с обработкой трайтов наткнулся.
E>>Scala, вероятно, посложнее Turbo C (ой ли). Но уж явно не сложнее MultiEdit-а.
M>А ты их ChangeLog-и читал? Почитай списки ошибок в стабильных продуктах, будешь сильно удивлён.
Нынешних стабильных или тогдашних?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
M>>А ты их ChangeLog-и читал? Почитай списки ошибок в стабильных продуктах, будешь сильно удивлён.
E>Нынешних стабильных или тогдашних?
E>Проблема в том, что существует поверье, мол чем выше язык, тем более сложные задачи он позволяет решать. А более простые задачи позволяет решать проше и быстрее. Так вот, больше всего меня интересует, раз Scala сейчас вбирает в себя все лучшее и работают над ним совсем не глупые люди, почему же у них в ChangeLog-е после первого релиз кандидата (это все-таки не бэта даже, а почти релиз) критические ошибки десятками вылазюют. Не сильно-то, видно, облегчает.
если простота програмимирования на языке возрастает в N раз, то сложность компилятора при этом возрастает наверно как N^2
Здравствуйте, BulatZiganshin, Вы писали:
BZ>если простота програмимирования на языке возрастает в N раз, то сложность компилятора при этом возрастает наверно как N^2
С++... и программировать трудно и компилятор хрен напишешь...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eao197, Вы писали:
E>Проблема в том, что существует поверье, мол чем выше язык, тем более сложные задачи он позволяет решать. А более простые задачи позволяет решать проше и быстрее.
Это не поверье, это — объективная реальность.
E>Так вот, больше всего меня интересует, раз Scala сейчас вбирает в себя все лучшее и работают над ним совсем не глупые люди, почему же у них в ChangeLog-е после первого релиз кандидата (это все-таки не бэта даже, а почти релиз) критические ошибки десятками вылазюют. Не сильно-то, видно, облегчает.
Ты исходишь из неверных предпосылок. Проблема не в высокоуровневости инструментов. Проблема в том, что языком занимаются учёные, а не инженеры. А учёные такой народ, который перестаёт пилить дерево после того как даказано, что теоретически оно может быть спилено. Ты же хочешь, чтобы они тебе и дерево спилили, и сучки обрубили, и обтесали, и распилили на доски.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
E>>Так вот, больше всего меня интересует, раз Scala сейчас вбирает в себя все лучшее и работают над ним совсем не глупые люди, почему же у них в ChangeLog-е после первого релиз кандидата (это все-таки не бэта даже, а почти релиз) критические ошибки десятками вылазюют. Не сильно-то, видно, облегчает.
IT>Ты исходишь из неверных предпосылок. Проблема не в высокоуровневости инструментов. Проблема в том, что языком занимаются учёные, а не инженеры. А учёные такой народ, который перестаёт пилить дерево после того как даказано, что теоретически оно может быть спилено. Ты же хочешь, чтобы они тебе и дерево спилили, и сучки обрубили, и обтесали, и распилили на доски.
Да мне вообще фиолетово, спилили ли они дерево или доказали возможность его спиливания от обратного, или же они его доказали возможность его распиливания по индукции.
Просто все это выглядит как еще одно доказательство правоты ДеМарко и Листера: человеческий фактор способен загубить любой инструмент.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Если посмотреть на ChangeLog языка Scala то количество строк вида Fixed compiler crash просто поражает (только в 2.6.0-RC2 по сравнению с 2.6.0-RC1 было исправлено 20 штук). Вот я и не понимаю: откуда вообще такое количество крэшей?
а что такого страшного в креше компилятора? ИМХО, это куда лучше чем генерация отфонарного кода или компиляция исходника, содержащего ошибки. В конце концов, это ж не синий экран смерти — даже никакие данные не потеряются. Так что "непадающий" компилятор — это вовсе не самоцель. Ну а ошибки есть в любой нетривиальной системе, да.
Здравствуйте, eao197, Вы писали:
E>В одной раз забабахали утверждения, что managed-языки и ФП -- рулез.
Т.е. ты предполагаешь, что если бы писали на unmanaged и без ФП, то список исправленных ошибок был короче?
now playing: Intelligent Communication — Open Loop