Вот я не понимаю... - Философия программирования

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

E>Или это вообще сейчас тенденция такая в софтостроении -- ничего стабильного нет, поскольку оплачивается скорость выхода продукта на рынок, а не его качество?

Эта тенденция была всегда. Объясняю на пальцах.
Есть программа с двумя элементами. Между ними одна связь. X — Y
Усложним программу, добавив ещё один элемент. Между ними уже будет 3 связи
X — Y
\ /
Z
Добавим ещё один элмемент, ещё один... Количество связей в программе растёт факториально!
При изменении каждого элемента тебе надо проверить все связи, любая может быть нарушена и программа получит ошибку.

Борьба с этой возрастающей сложностью — и есть основная проблема программирования. Именно для её решения выдумывают модульное, объектное программирование и прочие технологии. Они помогают уменьшить скорость роста взаимосвязей, инкапсулируют работу отдельных частей, уменьшают количество взаимосвязей. Но эти приёмы не всесильны. Вместо количества связей между глобальными переменными и функциями — появляются связи между классами. Было 100 элементов (глобальных переменных и функций), стало 10 классов. Код, конечно, стал сложнее и может много больше — в каждом классе у нас по несколько функций и полей. И теперь мы можем делать более сложные программы. И делаем. И получаем программу из 100 классов — и опять она приходит к порогу, за которым её сопровождение становится невозможным.

А ты думаешь, это из-за плохой кармы MS писала Vista 5 лет и потратила 6 миллиардов, реализовав меньше половины обещанных фич? Нет, просто они тоже упёрлись в этот порог. И раньше упирались, когда Windows 1.0 написали — только тогда это был порог сложности технологий того уровня.

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

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

BZ>если простота програмимирования на языке возрастает в N раз, то сложность компилятора при этом возрастает наверно как N^2
С++... и программировать трудно и компилятор хрен напишешь...

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

EC>Т.е. ты предполагаешь, что если бы писали на unmanaged и без ФП, то список исправленных ошибок был короче?

Конечно короче. Вот список неисправленных был бы намнооого длиннее.

... << RSDN@Home 1.2.0 alpha rev. 726>>

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

M>Здравствуйте, Стэн, Вы писали:

С>>Все началось вот с этого:
>>>>> Java программы падают от null-евых ссылок чаще, чем C++ные
С>>Так вот, в C++ если переменная объявлена как объект, а не как указатель на объект, то компилятор гарантирует, что объект будет инициализирован. Т.е. во время работы программы будет вызван соответствующий конструктор. Если программист указал параметры неправильного типа, либо нет подходящего конструктора, то будет ошибка времени компиляции. А еще у C++-ников есть привычка все указатели на объект заключать в какой-нибудь smart_ptr...
С>>В результете всего получается, что в программах на C++ кол-во указателей на объекты гараздо меньше чем на Java, а за теми, которые есть, следят более пристально... Отсюда и статистика падений по null-ссылкам не в пользу Java...

M>Вы уж извините, но это полный бред. Никакого отношения к нулевым указателям размещение объектов в хипе или стеке отношения не имеет. И ява точно так-же, как и остальные языки, гарантирует инициализации объекта. Даже более надёжно гарантирует — в виду наличия верификатора кода. К неинициализированной локальной переменной просто не может быть обращения, в отличие от С++, где это запросто, и выдаёт в ответ бодрый мусор.
M>Ошибки NullPointerException возникают исключительно по причине передачи null в качестве аргумента метода, и null ссылки в полях классов.

class Demo {
    static public void main( String[] args )
    {
        StringBuffer buf = findAppropriateBuffer();
        for( int i = 0; i != args.length; ++i )
            buf.append( args[ i ] );
        System.out.println( buf );
    }

    static private StringBuffer findAppropriateBuffer()
    {
        return null;
    }
}

ЗЫ Теперь понятно, почему тебе SymADE&SOP так понравился... ты просто не писал никогда сложных программ, не участвовал в сложных проектах.

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

E>Проблема в том, что существует поверье, мол чем выше язык, тем более сложные задачи он позволяет решать. А более простые задачи позволяет решать проше и быстрее.

Это не поверье, это — объективная реальность.

E>Так вот, больше всего меня интересует, раз Scala сейчас вбирает в себя все лучшее и работают над ним совсем не глупые люди, почему же у них в ChangeLog-е после первого релиз кандидата (это все-таки не бэта даже, а почти релиз) критические ошибки десятками вылазюют. Не сильно-то, видно, облегчает.

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

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

M>И что? buf явно проинициализирован. Тот, кто не прочитал спецификацию на возвращаемое значение — сам дурак.
M>Этот код точно так-же пишется на С/С++, только он выкинет не exception, а core dump.

На самом деле вы оба не правы.

Конечно Ява в сто раз безопаснее С++, так как просто недопускает порчи памяти и связанной с ней мучительной отладке наугад. Тут ты прав, а еао197 не прав.

Но, NPE (NullPointerException) — это огромный геморой современного мэйнстрима. И проблема в основном заключается в том, что null появляется там где программист о нем не подозревает.

Если быть более точным, то проблма кроется еще глубже. В современных мэйнстрим-языках отсуствует четкая семантика понятия необъязательный. NULL/null/0 зачастую используется как высокопроизводительная форма сообщить вызваашей стороне, что что-то отсусвтвует или не определено. То есть NULL/null/0 неформально получают семантику Optional/Default/Nothing/Error. Нигде кроме документации (которой может и не быть) подобные предположения (а как их еще назвать?) не описывают. В других же местах программист (чтобы упростить себе жизнь) считает, что сылка всегда указывает на что-то осмысленно. Ошибка в подобных предположениях в купе с забывчивостью и приводят к ошибкам.

Да ошибки, что называется, по дурости. Но уд больно они распространены.

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

Так вот в той же Скале тоже есть средство позволяющее явно указать семантику не "Optional". Незнаю как оно там назвается, но аналог в Немрле называется option[T]. Идея очень проста. Мы возвращаем не ссылку на объект типа T которая может быть null, а ссылку на option[T] (вариант который может иметь два значения Some(x : T) или None(). Далее обрабатывает их средствами паттерн-матчинга). Все остальные ссылки считаются недопускающими null. Так сделано в Хаскеле и вообще опчти всех клонах МЛ. Вот только одно "но". В виду совместимости с Явой и в следствии борьбы за производительность (ведь null дешевле чем лишняя косвенность и лишний оберточный объект), и Скала, и Немрерле не запрещают использование null-ссылок. Отслеживает ошибки только рантайм (компилятор тут бессилен, так как система типов не только допускает null-значения, но и инициализирует все ссылочные поля и переменные в null по умолчению).

Собственно средства борьбы уже готовится. В Spec# реализован аппорат контроля допустимости null во время компиляции. При этом система типов расширена типами !T аналогичной T но недопускающей null, а хитрая система проверки корректности теорем строит теоремы доказывающие корректное использование ссылок и проверяет их корректность. В эксперементальном режиме данная фича доступна и в Немерле. Но для ее использования прийдется понапрягаться (скачать и установить Spec#, подключить нестандратные пространства имен содержащих интеграцию и т.п.). Однако и при этом прийдтя немало времени уделить аннотациям типов, а результат не всгеда бует качественным.

Одитоживая скажу, что фактически проблема некорректных ссылок существует и в С++, и в Яве/дотнете, причем в С++ она имеет более дорогую цену, а единственным средством борьбы с проблемой является аккуратность программиста и соблюдение им разного рода паттернов программирования вроде исползования ссылок и смартпоинтров вместо указателей. Подобные техники есть и для Явы, но Ява все же, гарантирует целостность памяти, а значит снижает цену ошибки.

Хорошим выходом из ситуации было бы:
1. Отказаться от null в системе типов.
2. Ввести в систему типов аналог option[T] (нулабл-типы из дотнета не подходят, так как они применимы исключительно для вэйлью-типов).
3. Заставить программиста явно указывать, что ему нужен option[T]-тип, в тех местах где программист ранее передавал null в качестве некоторого сигнала.
4. Заставить компилятор требовать инициализации всех перменных не null-значениями.

Вот только это серьезное изменение и не только в компиляторах.

Как вариант — внедрить в жизнь технологии аля Spec#. Но пока что до этого далеко.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

MF>>Maintainable ==> качественный
MF>>тогда
MF>>Некачественный ==> Unmaintailable.
EC>Это твоё сообщение противоречит твоему предыдущему.
EC>Я именно это и утверждал.

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

E>Если посмотреть на ChangeLog языка Scala то количество строк вида Fixed compiler crash просто поражает (только в 2.6.0-RC2 по сравнению с 2.6.0-RC1 было исправлено 20 штук). Вот я и не понимаю: откуда вообще такое количество крэшей?

а что такого страшного в креше компилятора? ИМХО, это куда лучше чем генерация отфонарного кода или компиляция исходника, содержащего ошибки. В конце концов, это ж не синий экран смерти — даже никакие данные не потеряются. Так что "непадающий" компилятор — это вовсе не самоцель. Ну а ошибки есть в любой нетривиальной системе, да.

... << RSDN@Home 1.2.0 alpha rev. 717>>

Прошу прощения за флеймоопасную тему, может настроение просто такое

...

Если посмотреть на ChangeLog языка Scala то количество строк вида Fixed compiler crash просто поражает (только в 2.6.0-RC2 по сравнению с 2.6.0-RC1 было исправлено 20 штук). Вот я и не понимаю: откуда вообще такое количество крэшей?

Ладно бы язык был небезопасный. Так ведь нет, на JVM все, куда уж безопаснее. Да и не чисто императивный это язык, а императивно-функциональный гибрид. Ну т.е. самый писк нонче. Не чета древним C++ам.

И ладно бы один человек Scala занимался, может компилятор -- это сильно сложно для одного человека (хотя глядя на Вальтера Брайта...). Так ведь их же там десять разработчиков.

И ладно бы у них было строгое расписание и дедлайн, который профукать нельзя. Так ведь и этого не видно -- не обозначено у них точных сроков выхода 2.6.0 вообще.

Может у них просто подход к разработке такой -- пусть пользователи тестируют, то что мы не достестировали?

Или это вообще сейчас тенденция такая в софтостроении -- ничего стабильного нет, поскольку оплачивается скорость выхода продукта на рынок, а не его качество?

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

FR>>Нифига списки вполне сопоставимые http://www.digitalmars.com/d/changelog.html и по ICE тоже. Похоже на самом деле ошибки больше зависят от квалификации пишущих а не от используемого языка.

K>Надо учитывать, что компиляторы Scala и D по сложности, мягко говоря, сильно отличаются.

Ой-ли. Тем более, что человеко-лет (мифических, естественно), в разработку Scala было вложенно больше, чем в D.
К тому же DMD написан на C++.

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

E>>В одной раз забабахали утверждения, что managed-языки и ФП -- рулез.

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

Я просто очень большой ребенок

А любимые игрушки -- велосипеды

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

M>Вы уж извините, но это полный бред. Никакого отношения к нулевым указателям размещение объектов в хипе или стеке отношения не имеет.

Угу, имеет значение совсем другое. Насколько я понимаю в java любому объекту можно присвоить null. В С++ нет. И соответственно число ошибок обращения по нулевому указателю должно быть меньше. Ну и тот же RAII над которым так любят посмеятся поклоники манджед сред тоже имеет значение.

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

FR>>>Нифига списки вполне сопоставимые http://www.digitalmars.com/d/changelog.html и по ICE тоже. Похоже на самом деле ошибки больше зависят от квалификации пишущих а не от используемого языка.
K>>Надо учитывать, что компиляторы Scala и D по сложности, мягко говоря, сильно отличаются.

E>Ой-ли.

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

... << RSDN@Home 1.2.0 alpha rev. 726>>

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

M>Не понимаю логики , как связан upcasting с использованием полиморфизма?

Ты вынужден искать такие алгоритмы, так проектировать программу, чтоб тип данных был известен во время компиляции точно. Как следствие, тебе нужно меньше ссылок (потому как через ссылки полиморфизм и реализуется), и получается меньше null-евых ошибок.

M>Вообщет хороший стиль подразумевает минимизацию upcasting?

В C++ — наверняка.

ЗЫ В любом случае, это просто предположение.

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

EC>Т.е. о checked exceptions JVM ничего не знает?

Ничего.

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

VD>>Да и нужны тут не алгеброические типы, а аналог паттерн-матчинга.
EC>Насколько я понимаю паттерн матчинг это процесс обратный конструированию значения алгебраического типа.
EC>Хотя дело даже не в этом. NPE возможен когда у нас есть reference семантика.
EC>Например в Haskell он невозможен потому как там её просто нет (всякие извраты с IORef не в счёт).

В языке Nice, работающем поверх JVM, сделали хорошую попытку устранения NPE: http://nice.sourceforge.net/manual.html#optionTypes

Хотя в своей реализации они так и не смогли выловить все ветки if-ов при контроле ненулевых ссылок. А это наводит на мысль что подобный контроль в общем случае является слишком сложной задачей.

Что-то подобное хотят реализовать так же в ближайших версиях Eiffel-я.

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

E>В одной раз забабахали утверждения, что managed-языки и ФП -- рулез.

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

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

E>>Или это вообще сейчас тенденция такая в софтостроении -- ничего стабильного нет, поскольку оплачивается скорость выхода продукта на рынок, а не его качество?

M>Эта тенденция была всегда.

Довелось мне в течении тескольких лет использовать Turbo C 2.0 и MultiEdit 6-7. Что-то по моим воспоминаниям не всегда была эта тенденция.

Scala, вероятно, посложнее Turbo C (ой ли). Но уж явно не сложнее MultiEdit-а.

M>ЗЫ Теперь понятно, почему тебе Ruby так понравился... ты просто не писал никогда сложных программ, не участвовал в сложных проектах.

Да, повезло. Продолжаю пребывать в блаженном неведении.

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

E>Если посмотреть на ChangeLog языка Scala то количество строк вида Fixed compiler crash просто поражает (только в 2.6.0-RC2 по сравнению с 2.6.0-RC1 было исправлено 20 штук). Вот я и не понимаю: откуда вообще такое количество крэшей?
E>Ладно бы язык был небезопасный. Так ведь нет, на JVM все, куда уж безопаснее. Да и не чисто императивный это язык, а императивно-функциональный гибрид. Ну т.е. самый писк нонче. Не чета древним C++ам.
...
E>Может у них просто подход к разработке такой -- пусть пользователи тестируют, то что мы не достестировали?

Чего-то не пойму, в чем проблема. До релиза в продукте нашли и исправили некоторое количество ошибок, в чем можно обвинять разработчиков? Отличие безопасного от небезопасного языка тут проявляется понятно где — "крэшем" называют не дамп регистров и не порчу данных, а падение по исключению, ошибки в алгоритмах мейнстримные "безопасные" языки исправлять еще не научились (есть языки побезопаснее — Epigram, Omega, но захотите ли вы на них писать?).

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

M>>А ты их ChangeLog-и читал? Почитай списки ошибок в стабильных продуктах, будешь сильно удивлён.

E>Нынешних стабильных или тогдашних?

А ты уверен, что есть разница?

E>Проблема в том, что существует поверье, мол чем выше язык, тем более сложные задачи он позволяет решать. А более простые задачи позволяет решать проше и быстрее. Так вот, больше всего меня интересует, раз Scala сейчас вбирает в себя все лучшее и работают над ним совсем не глупые люди, почему же у них в ChangeLog-е после первого релиз кандидата (это все-таки не бэта даже, а почти релиз) критические ошибки десятками вылазюют. Не сильно-то, видно, облегчает.

если простота програмимирования на языке возрастает в N раз, то сложность компилятора при этом возрастает наверно как N^2

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

E>Да мне вообще фиолетово

Зачем ты тогда вообще начал этот топик?

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

E>>В одной раз забабахали утверждения, что managed-языки и ФП -- рулез.
EC>Т.е. ты предполагаешь, что если бы писали на unmanaged и без ФП, то список исправленных ошибок был короче?

Просто по моим субъективным впечатлениям, Java программы падают от null-евых ссылок чаще, чем C++ные. Пишут их, правда, разные люди. Но, вполне возможно, C++ требует более тчательного подхода к разработке. А Java позволяет писать тяп-ляп. Ну и результат такой же

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

FR>Нифига списки вполне сопоставимые http://www.digitalmars.com/d/changelog.html и по ICE тоже. Похоже на самом деле ошибки больше зависят от квалификации пишущих а не от используемого языка.

Надо учитывать, что компиляторы Scala и D по сложности, мягко говоря, сильно отличаются.

... << RSDN@Home 1.2.0 alpha rev. 726>>

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

EC>Качественный пишется всегда с трудом на любом языке.

Напомнило девиз настоящего программёра:

If it was hard to write, it should be hard to understand

Если качественный код пишется с трудом, код некачественный, потому что он не maintainable.

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

С>Все началось вот с этого:
>>>> Java программы падают от null-евых ссылок чаще, чем C++ные
С>Так вот, в C++ если переменная объявлена как объект, а не как указатель на объект, то компилятор гарантирует, что объект будет инициализирован. Т.е. во время работы программы будет вызван соответствующий конструктор. Если программист указал параметры неправильного типа, либо нет подходящего конструктора, то будет ошибка времени компиляции. А еще у C++-ников есть привычка все указатели на объект заключать в какой-нибудь smart_ptr...
С>В результете всего получается, что в программах на C++ кол-во указателей на объекты гараздо меньше чем на Java, а за теми, которые есть, следят более пристально... Отсюда и статистика падений по null-ссылкам не в пользу Java...

Вы уж извините, но это полный бред. Никакого отношения к нулевым указателям размещение объектов в хипе или стеке отношения не имеет. И ява точно так-же, как и остальные языки, гарантирует инициализации объекта. Даже более надёжно гарантирует — в виду наличия верификатора кода. К неинициализированной локальной переменной просто не может быть обращения, в отличие от С++, где это запросто, и выдаёт в ответ бодрый мусор.
Ошибки NullPointerException возникают исключительно по причине передачи null в качестве аргумента метода, и null ссылки в полях классов.

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

FR>>>>Нифига списки вполне сопоставимые http://www.digitalmars.com/d/changelog.html и по ICE тоже. Похоже на самом деле ошибки больше зависят от квалификации пишущих а не от используемого языка.
K>>>Надо учитывать, что компиляторы Scala и D по сложности, мягко говоря, сильно отличаются.

E>>Ой-ли.

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

Мое "ой-ли" относилось к вашему утверждению о том, что сложность компиляторов Scala и D слишком различаются. По моему мнению, D вовсе не проще Scala, скорее наоборот. Соответственно, и сложность компиляторов Scala и D не слишком различаются.

К тому же багтрекер, как ни крути, очень объективный показатель качества программного продукта (ну или разработчиков). Более объективный, может быть, чем мифические человеко-месяцы или KLOC-и.

E>К тому же багтрекер, как ни крути, очень объективный показатель качества программного продукта (ну или разработчиков). Более объективный, может быть, чем мифические человеко-месяцы или KLOC-и.

Не сказал бы что слишком обьективный. Но есть определённая корреляция — как правило, чем БОЛЬШЕ записей в багтреккере (всех вместе — открытых и закрытых), тем ВЫШЕ качество программного продукта.

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

FR>>>>>Нифига списки вполне сопоставимые http://www.digitalmars.com/d/changelog.html и по ICE тоже. Похоже на самом деле ошибки больше зависят от квалификации пишущих а не от используемого языка.
K>>>>Надо учитывать, что компиляторы Scala и D по сложности, мягко говоря, сильно отличаются.
E>>>Ой-ли.
K>>Т.е. это не надо учитывать? Вы утверждаете, что можно сравнивать языки по багтрекерам двух разных проектов, которые писали разные люди, разное время и на разных языках? Методикой не поделитесь, очень интересно.

E>Мое "ой-ли" относилось к вашему утверждению о том, что сложность компиляторов Scala и D слишком различаются. По моему мнению, D вовсе не проще Scala, скорее наоборот.

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

E>Соответственно, и сложность компиляторов Scala и D не слишком различаются.

Что значит не слишком? Вы как сложность оцениваете? Когда она различается еще "не слишком", а когда уже "слишком"? А без методики можно только констатировать факт о том, что они различаются, а значит сравнения некорректны.

E>К тому же багтрекер, как ни крути, очень объективный показатель качества программного продукта (ну или разработчиков). Более объективный, может быть, чем мифические человеко-месяцы или KLOC-и.

С чего бы это? Объективным показателем был бы, например, баг на еденицу сложности (да и то только в том случае, если бы мы могли получить полный список багов, а не список известных на данный момент). Или баг на еденицу функциональности — что гораздо интереснее, ведь определеный уровень функциональности системы может быть достигнут, условно говоря, при любой сложности не меньше определенной. А в чем измерять сложность или функциональность компилятора? Число известных багов на KLOC или на мифический человеко-месяц посчитать легко, но зато о сложности компилятора KLOC-и и человеко-месяцы не очень хорошо говорят (в том случае, если писали разные люди и на разных языках — практически ничего не говорят.)
Я посмотрел багтрекеры GHC и Nemerle — для GHC я не нашел группировки по типу ошибки (крэш компилятора или нет — для данного случая), а в компиляторе Nemerle за всю его историю было найдено 45 крэшей, причем как минимум один из них — из-за бага в .NET CLR. Ну и какой из этого следует вывод?

Допустим, есть реализации стандарта (например C#) на C++ и на C#. Тут, на основании данных по строкам кода и человеко-часам еще можно какие-то выводы делать, а сравнивая баги в трекере D и Scala мы получаем, что в огороде бузина, а в Киеве — дядька. И что?

... << RSDN@Home 1.2.0 alpha rev. 730>>

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

E>>Мое "ой-ли" относилось к вашему утверждению о том, что сложность компиляторов Scala и D слишком различаются. По моему мнению, D вовсе не проще Scala, скорее наоборот.

K>Наоборот — это значит, что D сложнее, чем Scala? Но ведь смысл моего утверждения никак не зависит от того, что сложнее D или Scala (у меня есть мнение на этот счет, но обсуждать его мне не интересно, в основном потому, что хорошей методики определения сложности я не знаю, а обосновать свое интуитивное впечатление о сложности невозможно)
K>Смысл в том, что сложность различается.

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

E>>Соответственно, и сложность компиляторов Scala и D не слишком различаются.

K>Что значит не слишком? Вы как сложность оцениваете?

Как сложность реализации транслятора, на основании собственного небольшого опыта реализации нескольких лексических/семантических анализаторов и мелких языков.

E>>К тому же багтрекер, как ни крути, очень объективный показатель качества программного продукта (ну или разработчиков). Более объективный, может быть, чем мифические человеко-месяцы или KLOC-и.

K>С чего бы это?

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

Но я не могу говорить о проектах в миллионы строк (вроде Windows), там мало багов быть по определению не может.

K>Я посмотрел багтрекеры GHC и Nemerle — для GHC я не нашел группировки по типу ошибки (крэш компилятора или нет — для данного случая), а в компиляторе Nemerle за всю его историю было найдено 45 крэшей, причем как минимум один из них — из-за бага в .NET CLR. Ну и какой из этого следует вывод?

А какой вывод вы хотели? Посмотрите на название темы. Я действительно не понимаю, почему на безопасной JVM и высокоуровневых языках Java и Scala в компиляторе Scala находят столько крэшей. Вот и по вашим данным в Nemerle их за всю историю нашли всего 45. А тут только после RC1 двадцать штук.

K>Допустим, есть реализации стандарта (например C#) на C++ и на C#. Тут, на основании данных по строкам кода и человеко-часам еще можно какие-то выводы делать, а сравнивая баги в трекере D и Scala мы получаем, что в огороде бузина, а в Киеве — дядька. И что?

А то и получаем -- качественные программы зависят от качественных программистов. Хороший инструмент нормальному разработчику только в помощь будет, а другому -- что Scala, что C++, все равно крэш на крэше.

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

FR>Нифига списки вполне сопоставимые http://www.digitalmars.com/d/changelog.html и по ICE тоже.

Сравнивать надо схожие по сложности вещи. Вот Немреле и Скала сравнимы. Ди еще до них расти и расти.
У Ди только один показатель похож — объем кода компилятора. Так что это скорее подтверждает империческое правило, что объем ошибок примерно одинаков и пропорционален объему кода (больеш код, больше ошибок). И то что на более мощьных языках проще писать более сложные вещи.

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

S>Так Влад и предлагает ввести пустой объект "соседнего" класса.

Не, паттерн null object проблемы не решает. Ну будет вместо NPE исключение при обращении к полям null object — только косвенность увеличится. Влад другое предлагает — ввести хотя бы частичный контроль за null на стадии компиляции, а не в рантайме.

... << RSDN@Home 1.2.0 alpha rev. 716>>

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

C>В Java в IDEA есть подобная фича — можно ставить аннотации @NotNull на
C>параметры методов, поля класса и т.п. Инспектор будет автоматически
C>проверять это при компиляции на этапе инспекции.

В решарпере тоже.

C>Использую в проекте везде. Я бы не сказал, что мне это сильно помогает —
C>но какое-то число ошибок сразу при редактировании отлавливается.

А это потому что оно не обязательно, и стандартная библиотека не аннотирована.

... << RSDN@Home 1.2.0 alpha rev. 716>>

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

E>>>>В одной раз забабахали утверждения, что managed-языки и ФП -- рулез.

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

E>>Я просто очень большой ребенок

А любимые игрушки -- велосипеды

VD>Это было не странное если не одно "но". Нормальные дети любят кататься на велосипедах, а не зацикливаются на их изобретении.

А кто здесь настаивал на нормальности?

PS. Смотрю тебе так же захотелось покидаться дерьмом в вентилятор.

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

L>Что мне помешает написать

L>

L>toChar :: a -> Char
L>toChar = fromJust . cast
L>

L>?

L>

Это — сознательное переведение ситуации на язык throw errors:

fromJust          :: Maybe a -> a
fromJust Nothing  = error "Maybe.fromJust: Nothing" -- yuck
fromJust (Just x) = x

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

S>Мир несовершенен. Тебе один хрен может прийти null "снаружи" — ведь не весь код написан на новой технологии.

Это почему же это? Если что всегда можно сделать обертку которая проверит параметры "внешнего" метода на нал и переведет нас в координаты правильной системы типов. Ну, что-то вроде интеропа в дотнете.

S> Да и внутри твоей программы могут понадобиться опциональные значения.

Читай внимательнее. Для этого есть option[T].

S> Заметь, во второй шарп ввели Nullable типы ровно для тех, у которых нулла вовсе не было. Значит — есть спрос!

Заметил. Мой вывод был однозначинй — уроды!
А спрос на дерьмо есть только если нет предолжения не основанного на нем.

S>Я всё прекрасно понял.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

S>>Мир несовершенен. Тебе один хрен может прийти null "снаружи" — ведь не весь код написан на новой технологии.

VD>Это почему же это? Если что всегда можно сделать обертку которая проверит параметры "внешнего" метода на нал и переведет нас в координаты правильной системы типов. Ну, что-то вроде интеропа в дотнете.
Совершенно верно. И если параметр оказался нал, то что? Правильно, NPE. Но только NPE возникнет не в недрах нашего кода, через неопределенное время после поступления в него, а сразу же при попытке пересечь границы нашей системы. Ну либо там будет стоять сразу же проверка на null и корректная реакция.
VD>Читай внимательнее. Для этого есть option[T].
Да нормально я читаю. Мы говорим об одном и том же.
S>> Заметь, во второй шарп ввели Nullable типы ровно для тех, у которых нулла вовсе не было. Значит — есть спрос!
VD>Заметил. Мой вывод был однозначинй — уроды!
Очень странно. Nullable<int> — это ровно тот же option[int], вид сбоку.
Есть два способа привести от int? к int: безопасный и небезопасный.
Вот метод грубой силы:

int? n = null;
int a = (int)n;

Мы получим NPE.
Вот безопасный метод в более похожем на Nemerle стиле:

int? n = null;
int a = n ?? 0;

Чего не хватает в дотнете — это обратной штуки для reference-типов. Точнее, ее можно сделать самому, но без поддержки со стороны компилятора ее полезность близка к нулю.
Я склонен согласиться, что имело бы смысл и для референс типов сделать non-nullable тип основным, а возможность использовать null нужно было бы указывать явно.
VD>А я вот увер, что нет. Ну, или не подумал как следует. Попробуй перечитать все сказанное еще рез. Уверен, что ты поймешь о чем я говорю.
Влад, я всё уже прочитал и понял.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

От плохих программистов? Возможно, ученые, которые её создали, весьма подкованы в теории и создали логичный и целостный язык, но в реализации оказались не очень. Стоит поглядеть её исходный код.

Здравствуйте, 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-е после первого релиз кандидата (это все-таки не бэта даже, а почти релиз) критические ошибки десятками вылазюют. Не сильно-то, видно, облегчает.

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

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

E>>>>Или это вообще сейчас тенденция такая в софтостроении -- ничего стабильного нет, поскольку оплачивается скорость выхода продукта на рынок, а не его качество?

M>>>Эта тенденция была всегда.

E>>Довелось мне в течении тескольких лет использовать Turbo C 2.0 и MultiEdit 6-7. Что-то по моим воспоминаниям не всегда была эта тенденция.

M>Ты пользовал Scala и она у тебя на всех этих, отмеченных в ChangeLog, ситуациях падала?
M>Из тысяч пользователей она падает у одного, он сабмитит ошибку и её правят. Остальные об этой ошибке никогда и не узнают, если не читают ChangeLog.

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

E>>Scala, вероятно, посложнее Turbo C (ой ли). Но уж явно не сложнее MultiEdit-а.

M>А ты их ChangeLog-и читал? Почитай списки ошибок в стабильных продуктах, будешь сильно удивлён.

Нынешних стабильных или тогдашних?

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

E>>Так вот, больше всего меня интересует, раз Scala сейчас вбирает в себя все лучшее и работают над ним совсем не глупые люди, почему же у них в ChangeLog-е после первого релиз кандидата (это все-таки не бэта даже, а почти релиз) критические ошибки десятками вылазюют. Не сильно-то, видно, облегчает.

IT>Ты исходишь из неверных предпосылок. Проблема не в высокоуровневости инструментов. Проблема в том, что языком занимаются учёные, а не инженеры. А учёные такой народ, который перестаёт пилить дерево после того как даказано, что теоретически оно может быть спилено. Ты же хочешь, чтобы они тебе и дерево спилили, и сучки обрубили, и обтесали, и распилили на доски.

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

Просто все это выглядит как еще одно доказательство правоты ДеМарко и Листера: человеческий фактор способен загубить любой инструмент.

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

E>>Да мне вообще фиолетово

IT>Зачем ты тогда вообще начал этот топик?

В одной раз забабахали утверждения, что managed-языки и ФП -- рулез.

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

E>В одной раз забабахали утверждения, что managed-языки и ФП -- рулез.
Т.е. ты предполагаешь, что если бы писали на unmanaged и без ФП, то список исправленных ошибок был короче?

now playing: Intelligent Communication — Open Loop

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

E>Просто по моим субъективным впечатлениям, Java программы падают от null-евых ссылок чаще, чем C++ные. Пишут их, правда, разные люди. Но, вполне возможно, C++ требует более тчательного подхода к разработке. А Java позволяет писать тяп-ляп. Ну и результат такой же

Требовать может и требует, но на нём точно так же пишут как придётся.
Я видел много кода, что на C++, что на VB или C# и не заметил, чтобы качество плюсового было в среднем лучше.
Качественный пишется всегда с трудом на любом языке.

now playing: Architect — Belgian Connection

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

E>Просто по моим субъективным впечатлениям, Java программы падают от null-евых ссылок чаще, чем C++ные. Пишут их, правда, разные люди. Но, вполне возможно, C++ требует более тчательного подхода к разработке. А Java позволяет писать тяп-ляп. Ну и результат такой же

Скорее дел в том, что в C++ есть стековые объекты, которые создаются автоматически, а в Java все объекты должны создаваться явно в куче. Кстати, в Delphi — таже ситуация и те же проблемы.

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

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

EC>>Т.е. ты предполагаешь, что если бы писали на unmanaged и без ФП, то список исправленных ошибок был короче?

K>Конечно короче. Вот список неисправленных был бы намнооого длиннее.

Нифига списки вполне сопоставимые http://www.digitalmars.com/d/changelog.html и по ICE тоже. Похоже на самом деле ошибки больше зависят от квалификации пишущих а не от используемого языка.

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

EC>>Т.е. ты предполагаешь, что если бы писали на unmanaged и без ФП, то список исправленных ошибок был короче?

K>Конечно короче. Вот список неисправленных был бы намнооого длиннее.

Об этом, собственно и речь.

now playing: Implex — PI

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

С>Скорее дел в том, что в C++ есть стековые объекты, которые создаются автоматически, а в Java все объекты должны создаваться явно в куче. Кстати, в Delphi — таже ситуация и те же проблемы.
Вы не правы. ЯП Java исключает размещение объектов на стеке неспроста: внутри JVM [кажется, с версии Java SE 6 (Mustang)] встроен т.н. escape-анализ, который делает это действие за программиста. А с учетом того, что это делается в паре с динамической компиляцией JIT-ом, то... скорее именно C++ здесь аутсайдер.

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

С>>Скорее дел в том, что в C++ есть стековые объекты, которые создаются автоматически, а в Java все объекты должны создаваться явно в куче. Кстати, в Delphi — таже ситуация и те же проблемы.
R>Вы не правы. ЯП Java исключает размещение объектов на стеке неспроста: внутри JVM [кажется, с версии Java SE 6 (Mustang)] встроен т.н. escape-анализ, который делает это действие за программиста. А с учетом того, что это делается в паре с динамической компиляцией JIT-ом, то... скорее именно C++ здесь аутсайдер.

Не прав в чем? Например, что в Delphi одна из самых распространенных ошибок Access Violation (по нулевому адресу)? И это именно из-за того, что каждый объект должен создаваться динамически во время работы программы и на этапе компиляции нет возможности проверить — будет ли создан объект или нет.
Про Java у меня меньше знаний, но вопрос: если у класса в Java два конструктора с параметрами, то вызов какого из них будет сделан за программиста?

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

С>Не прав в чем? Например, что в Delphi одна из самых распространенных ошибок Access Violation (по нулевому адресу)? И это именно из-за того, что каждый объект должен создаваться динамически во время работы программы и на этапе компиляции нет возможности проверить — будет ли создан объект или нет.
А где это можно достоверно определить на этапе компиляции? Скажем, в Java/.NET конструктор может пробросить исключение, это единственный доступный конструктору способ "отказаться от создания объекта". Или я не о том?

С>Про Java у меня меньше знаний, но вопрос: если у класса в Java два конструктора с параметрами, то вызов какого из них будет сделан за программиста?
Вопрос не понял. Отвечаю, как понял: никакого.

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

MF>Если качественный код пишется с трудом, код некачественный, потому что он не maintainable.
С какого перепугу из качественности кода следует его unmaintainability?
Maintainability как раз главный показатель качества.
Оно перпендикулярно усилиям потраченным на написание.

now playing: Pornbugs — Freaky Persons

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

R>Здравствуйте, Стэн, Вы писали:

С>>Не прав в чем? Например, что в Delphi одна из самых распространенных ошибок Access Violation (по нулевому адресу)? И это именно из-за того, что каждый объект должен создаваться динамически во время работы программы и на этапе компиляции нет возможности проверить — будет ли создан объект или нет.
R>А где это можно достоверно определить на этапе компиляции? Скажем, в Java/.NET конструктор может пробросить исключение, это единственный доступный конструктору способ "отказаться от создания объекта". Или я не о том?

С>>Про Java у меня меньше знаний, но вопрос: если у класса в Java два конструктора с параметрами, то вызов какого из них будет сделан за программиста?
R>Вопрос не понял. Отвечаю, как понял: никакого.

Все началось вот с этого:
>>> Java программы падают от null-евых ссылок чаще, чем C++ные
Так вот, в C++ если переменная объявлена как объект, а не как указатель на объект, то компилятор гарантирует, что объект будет инициализирован. Т.е. во время работы программы будет вызван соответствующий конструктор. Если программист указал параметры неправильного типа, либо нет подходящего конструктора, то будет ошибка времени компиляции. А еще у C++-ников есть привычка все указатели на объект заключать в какой-нибудь smart_ptr...
В результете всего получается, что в программах на C++ кол-во указателей на объекты гараздо меньше чем на Java, а за теми, которые есть, следят более пристально... Отсюда и статистика падений по null-ссылкам не в пользу Java...

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

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

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

R>Здравствуйте, Стэн, Вы писали:

С>>Скорее дел в том, что в C++ есть стековые объекты, которые создаются автоматически, а в Java все объекты должны создаваться явно в куче. Кстати, в Delphi — таже ситуация и те же проблемы.
R>Вы не правы. ЯП Java исключает размещение объектов на стеке неспроста: внутри JVM [кажется, с версии Java SE 6 (Mustang)] встроен т.н. escape-анализ, который делает это действие за программиста. А с учетом того, что это делается в паре с динамической компиляцией JIT-ом, то... скорее именно C++ здесь аутсайдер.

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

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

FR>Насколько я понимаю сейчас java это делает на порядок хуже чем нормальный программист вручную на C++.
Почему вы так думаете?

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

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

R>Здравствуйте, FR, Вы писали:
FR>>Тем более на C++ все гарантированно а на java может быть разместит а может и нет, гарантий никаких.
R>Гарантий, конечно, никаких, ведь при условии динамической компиляции выделение памяти на куче может быть через некоторое время сконвертировано в выделение на стеке.

Дак вопрос не в самом месте размещения объектов, а в гарантиях налагаемых на принимаемые условия. Примером слабости таких в JVM и .Net может служить ветка в немерловом форуме про notnullable ссылки, которые там (в Н) нельзя получить из-за модели самой платформы (дотнета).

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

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

FR>>Насколько я понимаю сейчас java это делает на порядок хуже чем нормальный программист вручную на C++.
R>Почему вы так думаете?

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

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

Угу а на C++ железно будет на стеке и будет и шустрее и надежнее (относительно NULL и освобождения ресурсов).

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

E>

E>class Demo {
E>    static public void main( String[] args )
E>    {
E>        StringBuffer buf = findAppropriateBuffer();
E>        for( int i = 0; i != args.length; ++i )
E>            buf.append( args[ i ] );
E>        System.out.println( buf );
E>    }

E>    static private StringBuffer findAppropriateBuffer()
E>    {
E>        return null;
E>    }
E>}
E>

И что? buf явно проинициализирован. Тот, кто не прочитал спецификацию на возвращаемое значение — сам дурак.
Этот код точно так-же пишется на С/С++, только он выкинет не exception, а core dump.

E>ЗЫ Теперь понятно, почему тебе SymADE&SOP так понравился... ты просто не писал никогда сложных программ, не участвовал в сложных проектах.

В SymADE для отслеживания нулевых указателей и гарантии, что не будет NullPointerException нужно всего-то написать плагин к компилятору, что делается одним человеком за пару месяцев (и наверняка будет написан уже до того, как большинству он понадобится). В Java для этого нужно менять синтаксис языка (JSR-308), и переписывать все средства программирования, от javac до Eclipse. Это займёт несколько лет минимум, и будет сделано не так, как нужно для конкретных проектов — как и произошло с assert, enum, generic types.

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

M>Объекту вообще нельзя присвоить null. Его можно присвоить только ссылке на объект. Точно так-же, как в C++.

В С++ ссылке присвоить NULL без хаков затруднительно

Но дело не в этом а в том что в C++ есть не только ссылочные объекты.

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

M>>Объекту вообще нельзя присвоить null. Его можно присвоить только ссылке на объект. Точно так-же, как в C++.

FR>В С++ ссылке присвоить NULL без хаков затруднительно

Не путай, то, что слова одинаковые, не означает одинакового смысла. В яве ссылка соответствует C-шному указателю.

FR>Но дело не в этом а в том что в C++ есть не только ссылочные объекты.

На автоматических переменных это никак не сказывается. Все локальные переменные должны быть проинициализированы, а проинициализированы ссылкой на объект в хипе, или созданы на стеке — имеет отношение только к скорости работы (кстати, аллокатор в нынешних явах — для каждого треда отдельный, и в виду heap compaction, затраты на него не превышают пары инструкций процессора).
Большее количество проблем с null в чём-то другом. Может в том, что все объекты наследуются от одного класса, или ещё в чём-то, но не в автоматических переменных — с ними контроль более жёсткий, чем в C++.

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

M>И что? buf явно проинициализирован. Тот, кто не прочитал спецификацию на возвращаемое значение — сам дурак.
M>Этот код точно так-же пишется на С/С++, только он выкинет не exception, а core dump.

Подучили бы C++ прежде чем такие заявления делать. В C++ можно возвращать объекты по значению. В этом случае NULL объекту вообще нельзя будет присвоить.

А в Java -- пожалуйста. И шибко умный компилятор Java может только проверить, что переменная-ссылка получила значение, но какое это значение компилятор Java понять уже не может. А вот компилятор Nice -- может.

Кроме того, это пример явно демонстрирует некорректность вашего категоричного утверждения:

Ошибки NullPointerException возникают исключительно по причине передачи null в качестве аргумента метода, и null ссылки в полях классов.

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

M>Большее количество проблем с null в чём-то другом. Может в том, что все объекты наследуются от одного класса, или ещё в чём-то, но не в автоматических переменных — с ними контроль более жёсткий, чем в C++.

А как объяснить тот факт, что способ создания объектов в Delphi похож на то, что в Java, и там тоже большое кол-во проблем с null (nil)?
И как влияет на это общий базовый класс?

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

С>А как объяснить тот факт, что способ создания объектов в Delphi похож на то, что в Java, и там тоже большое кол-во проблем с null (nil)?

Да, что-то общее есть. И другая закономерность есть — практически все люди, евшие огурцы — уже померли или вскоре помрут. Тоже загадка...

С>И как влияет на это общий базовый класс?

Это мне так почудилось. После дальнейших размышлений — от этой идеи я отказался. Появилась другая — в С++ нет (небыло долгое время, и сейчас нет, если выключить RTTI) безопасного способа upcasting-а, легче определение и код для невиртуальных методов — как результат, в нём меньше шаманят с полиморфизмом, используют другие приёмы проектирования. А полиморфизм через ссылки/указатели и может быть только реализован, то есть сама структура языка меньше располагает к использованию указателей вообще, и как следствие — NULL в частности.

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

[]

M>Это мне так почудилось. После дальнейших размышлений — от этой идеи я отказался. Появилась другая — в С++ нет (небыло долгое время, и сейчас нет, если выключить RTTI) безопасного способа upcasting-а, легче определение и код для невиртуальных методов — как результат, в нём меньше шаманят с полиморфизмом, используют другие приёмы проектирования. А полиморфизм через ссылки/указатели и может быть только реализован, то есть сама структура языка меньше располагает к использованию указателей вообще, и как следствие — NULL в частности.

Прости, но ты пишешь ерунду.

пс: полиморфизм использую чуть-ли не на каждом шагу, но вот upcasting'а нету нигде (за исключением комовского QI).

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

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

EC>С какого перепугу из качественности кода следует его unmaintainability?
EC>Maintainability как раз главный показатель качества.
EC>Оно перпендикулярно усилиям потраченным на написание.

Элементарная логика. Следи за руками.
Maintainable ==> качественный
тогда
Некачественный ==> Unmaintailable.

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

MF>Maintainable ==> качественный
MF>тогда
MF>Некачественный ==> Unmaintailable.
Это твоё сообщение противоречит твоему предыдущему.
Я именно это и утверждал.

now playing: Psidream — Magrathea

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

M> Появилась другая — в С++ нет (небыло долгое время, и сейчас нет, если выключить RTTI) безопасного способа upcasting-а, легче определение и код для невиртуальных методов — как результат, в нём меньше шаманят с полиморфизмом, используют другие приёмы проектирования.

Не понимаю логики , как связан upcasting с использованием полиморфизма? Вообщет хороший стиль подразумевает минимизацию upcasting?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>Scala, вероятно, посложнее Turbo C (ой ли). Но уж явно не сложнее MultiEdit-а.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

>... ChangeLog языка Scala ...
E>Проблема в том, что существует поверье, мол чем выше язык, тем более сложные задачи он позволяет решать. А более простые задачи позволяет решать проше и быстрее. Так вот, больше всего меня интересует, раз Scala сейчас вбирает в себя все лучшее и работают над ним совсем не глупые люди, почему же у них в ChangeLog-е после первого релиз кандидата (это все-таки не бэта даже, а почти релиз) критические ошибки десятками вылазюют. Не сильно-то, видно, облегчает.

Смотрим этот лог...
Первая ошибка связана с ошибкой в паттерн-матчинге. Тут вина в том, что язык доупскает пдобное. Прчем делает это довольно легко. В том же Немерле приняли решение по умолчанию использовать закрытые типы и проверки на полноту матчей. В прочем достаточно добавить образец "_" и с ним сопоставится все что угодно (контроль будет выключен).
Вторая — это банальное срабатывание ассерта.
Третья — NullPointerException. Одна из главнеших проблем всех мэйнстрим-лайк (так чтоли их назвать) языков. Точнее языков с С++-подобной системой типов основаной на классах и их экземлярах. Подобное невозможно в Хаскеле или МЛ, но и там могут быть проблемы с option/mayby.
Следующий (#29) — опять ассерт сработал.
#28 — ошибка в компиляторе выявленная исключением. Считай тот же ассерт.

Дальше влом смотреть. Ясно что это банальные ошибки выявленные при тестировании.

Видмо сбивает с толку слово "краш".
Лично я согласен с palm mute. Это именно что ошибки выяляемые в процессе тестирования.
Сравнивать же тут что-то с С++ просто бесмысленно. Объем кода на этом языке был бы в разы (а то и порядки) больше и проблем, соотвественно, было бы так же больше. Причем краши были бы уже не исключениями, а веселыми падениями с порчей памяти (не все, конечно, но многие).

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

Все программы глючат. Сложные — тем более.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>Мое "ой-ли" относилось к вашему утверждению о том, что сложность компиляторов Scala и D слишком различаются.

Как человек занимающийся компилятором похожего языка подтверждаю, что компиляторы языков Scala и D очень сильно разничаются по сложности. И это различие не в пользу Ди.

E>По моему мнению, D вовсе не проще Scala, скорее наоборот. Соответственно, и сложность компиляторов Scala и D не слишком различаются.

Твое мнение вообще не ясно откуда взялось.
В Ди нет половины фич, что есть в Скале. А те что есть реализованы не полностью. Или мод сложностью Ди ты понимашь трудность программирования на нем?

E>К тому же багтрекер, как ни крути, очень объективный показатель качества программного продукта (ну или разработчиков). Более объективный, может быть, чем мифические человеко-месяцы или KLOC-и.

Багтрекер — показатель качества?
Это значит, что чем меньше список исправленных багов, тем надежнее продукт?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

FR>Угу, имеет значение совсем другое. Насколько я понимаю в java любому объекту можно присвоить null. В С++ нет. И соответственно число ошибок обращения по нулевому указателю должно быть меньше. Ну и тот же RAII над которым так любят посмеятся поклоники манджед сред тоже имеет значение.

И тем не менее С++-программы вылетают по AV пожалуй чаще всего.
И дело тут в том, что в С++ есть 101 способ сделать ошибку связаннаю с указателями. В том числе тому способствует отсуствие гарантированной инициализции и мухлеж с типами. Причем последствия получаются куда страшнее чем NPE.

ЗЫ

NPE я не защищаю. Грамотным решением проблемы считаю подход МЛ-ь подобных языкво — введние специального типа для инкапсуляции значений которые могут быть неопределены и полный запрет на использование null. В прочем, без обязательной инициализации переменных и без отказа от

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>>>В одной раз забабахали утверждения, что managed-языки и ФП -- рулез.

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

E>Я просто очень большой ребенок

А любимые игрушки -- велосипеды

Это было не странное если не одно "но". Нормальные дети любят кататься на велосипедах, а не зацикливаются на их изобретении.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Хорошим выходом из ситуации было бы:
VD>1. Отказаться от null в системе типов.

Нереально. То есть можно "как правило" отказаться (введя "пустой объект" данного класса, скажем пустую строку для строк), за исключением небольшого числа случаев (0 тоже долго не считали числом, но потом решили, что уж слишком удобное понятие).
Но это будет не сильно большим выходом, ошибки NPE сейчас — чаще всего замаскированная другая ошибка. В каком-то смысле NPE — это автоматически расставляемые компилятором/VM ассерты. Не будет NPE — будут ещё более трудно уловимые баги.

VD>2. Ввести в систему типов аналог option[T] (нулабл-типы из дотнета не подходят, так как они применимы исключительно для вэйлью-типов).

Не очень удобно, IMHO, так как не-null можно рассматривать как один из constraint-ов данных. Могут быть и другие условия, вроде interned объектов (которые можно сравнивать на равенство по ссылке, а не по значению). Если на одину ссылку наложить несколько условий — то не понятно в каком порядке их "оборачивать" в эти врапперы.

VD>3. Заставить программиста явно указывать, что ему нужен option[T]-тип, в тех местах где программист ранее передавал null в качестве некоторого сигнала.

И чтоб это было опционально. То есть программист мог включать для отдельных модулей проверку на NPE, и эта ошибка тогда будет проверяться на стадии компиляции.

VD>4. Заставить компилятор требовать инициализации всех перменных не null-значениями.

Что невозможно, по причинам (1). Или тогда надо делать это эквивалентным (2).

VD>Как вариант — внедрить в жизнь технологии аля Spec#. Но пока что до этого далеко.

Надо почитать что у них там...

... << RSDN@Home 1.2.0 alpha rev. 677>>

Sinclair wrote:
> Нет, не будет. Багов будет столько же, только ловиться будут быстрее.
> Как правило, у какого-то значения есть мало источников, зато много
> потребителей. (Типа поле инициализируется одним из трех конструкторов, а
> потом читается в полусотне методов). Внедрение non-null позволит раньше
> отловить передачу некорректного значения.
В Java в IDEA есть подобная фича — можно ставить аннотации @NotNull на
параметры методов, поля класса и т.п. Инспектор будет автоматически
проверять это при компиляции на этапе инспекции.

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

Posted via RSDN NNTP Server 2.1 beta

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

AVK>В решарпере тоже.
AVK>А это потому что ... стандартная библиотека не аннотирована.

Скоро это изменится.

Молчу, молчу... Ребята скоро сами расскажут.

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

VD>2. Ввести в систему типов аналог option[T] (нулабл-типы из дотнета не подходят, так как они применимы исключительно для вэйлью-типов).
Они не решают эту проблему и для value types — меня компилятор не обязывает проверять есть ли значение в обёртке.
Это подходит только для систем типов с алгебраическими типами данных.

now playing: Marcus Meinhardt — Impacto

Здравствуйте, AndrewVK, Вы писали:
AVK>Не, паттерн null object проблемы не решает. Ну будет вместо NPE исключение при обращении к полям null object — только косвенность увеличится.
Это если не пользоваться non-null object

Просто non-null выбросит NPE не при использовании, как сейчас, а при присваивании.
AVK>Влад другое предлагает — ввести хотя бы частичный контроль за null на стадии компиляции, а не в рантайме.
Частичный — да. На стадии компиляции просто будет принудительно проверяться наличие проверок в оговоренных разработчиком местах.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

M>Нереально. То есть можно "как правило" отказаться (введя "пустой объект" данного класса, скажем пустую строку для строк), за исключением небольшого числа случаев (0 тоже долго не считали числом, но потом решили, что уж слишком удобное понятие).
M>Но это будет не сильно большим выходом, ошибки NPE сейчас — чаще всего замаскированная другая ошибка. В каком-то смысле NPE — это автоматически расставляемые компилятором/VM ассерты. Не будет NPE — будут ещё более трудно уловимые баги.

Это может выглядело бы нереально, если бы не было реализовано в целом ряде языков (см. ML, Хаскель, к примеру).

M>Не очень удобно, IMHO, так как не-null можно рассматривать как один из constraint-ов данных. Могут быть и другие условия, вроде interned объектов (которые можно сравнивать на равенство по ссылке, а не по значению). Если на одину ссылку наложить несколько условий — то не понятно в каком порядке их "оборачивать" в эти врапперы.

Это какая-то наукооразная ахинея, уж извини за грубость. Я уже сказал, что и где читать. Там все описано очень подробно. Давай не перемалывать воду в ступе. ОК?

VD>>3. Заставить программиста явно указывать, что ему нужен option[T]-тип, в тех местах где программист ранее передавал null в качестве некоторого сигнала.

M>И чтоб это было опционально. То есть программист мог включать для отдельных модулей проверку на NPE, и эта ошибка тогда будет проверяться на стадии компиляции.

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

VD>>4. Заставить компилятор требовать инициализации всех перменных не null-значениями.

M>Что невозможно, по причинам (1). Или тогда надо делать это эквивалентным (2).

В корне не верно. Именно наличие пунктов 1 и 2 повзоялет осуществить пункт 3. Компилятор должен производить анализ потока вычисления и требовать, чтобы любое поле любого объекта было инициализированно каким-то не null-значением. option[T] не является null-ом, так что все ОК.

Можно даже сказать, что п. 3 и п. ё1 — это следствие одного и того же решения. Просто п. 3 — это скорее реализация, а не требование.

VD>>Как вариант — внедрить в жизнь технологии аля Spec#. Но пока что до этого далеко.

M>Надо почитать что у них там...

Давно бы занялся. Уверяю тебя как минимум 90% вопросов сами собой исчезнут.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

M>>Нереально. То есть можно "как правило" отказаться (введя "пустой объект" данного класса, скажем пустую строку для строк), за исключением небольшого числа случаев (0 тоже долго не считали числом, но потом решили, что уж слишком удобное понятие).
S>Так Влад и предлагает ввести пустой объект "соседнего" класса.

Не очень понял термин "соседнего", но не суть. Тут вводится специальный объект который явно вводит понятие "не определено". Это заставляет компилятор выявлять места некорректного использования. С экземляром такого объекта нельзя будет попытаться произвести вычисление и получить исключение. Ты обязан будешь явно проверить, что объект задан и только после этого воспользоваться им. Вот только для реализации этого уже надо расширять язык. В клонах МЛ (коими являются Немреле и Скала) для этого используется паттерн-матчинг:

public modul Test
{
  public Method1(x : option[string], y : option[int]) : void
    {
        match (x, y)
        {
            | (Some(xVal), Some(yVal)) => WriteLine($"x=$xVal y=$yVal");
            | (None, None)             => WriteLine("x and y not set!");
            | (_, _)                   => WriteLine("x or y not set!");
        }
    }
}

Без паттерн-матчинга все будет не так красиво. Это часть концепции. Концепции очнь красивой и стройной.

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

M>>Но это будет не сильно большим выходом, ошибки NPE сейчас — чаще всего замаскированная другая ошибка. В каком-то смысле NPE — это автоматически расставляемые компилятором/VM ассерты. Не будет NPE — будут ещё более трудно уловимые баги.
S>Нет, не будет. Багов будет столько же, только ловиться будут быстрее. Как правило, у какого-то значения есть мало источников, зато много потребителей. (Типа поле инициализируется одним из трех конструкторов, а потом читается в полусотне методов). Внедрение non-null позволит раньше отловить передачу некорректного значения.

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

match (x : object)
{
    | x is int    => ... // x имеет тип int  
    | x is string => ... // x имеет тип string 
    | _           => ... // тип x другой... неизвестный нам...
}

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

M>>Не очень удобно, IMHO, так как не-null можно рассматривать как один из constraint-ов данных. Могут быть и другие условия, вроде interned объектов (которые можно сравнивать на равенство по ссылке, а не по значению). Если на одину ссылку наложить несколько условий — то не понятно в каком порядке их "оборачивать" в эти врапперы.
S>Это верно. Правильным ответом, безусловно, является паттерн-матчинг. Но реально NPE — это 98% констреинтов.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

S>>Так Влад и предлагает ввести пустой объект "соседнего" класса.

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

Ага. Только не "хотя бы частичный", а полный. Но к сожалению — это скорее всего без именения рантайма не прокатит. Так что СпекШарп похоже выглядет более реальным.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

AVK>>Не, паттерн null object проблемы не решает. Ну будет вместо NPE исключение при обращении к полям null object — только косвенность увеличится.
S>Это если не пользоваться non-null object

S>Просто non-null выбросит NPE не при использовании, как сейчас, а при присваивании.

Дык, а зачем вообще исключения когда можно остановить проблему в зародыше (при компиляции)?

AVK>>Влад другое предлагает — ввести хотя бы частичный контроль за null на стадии компиляции, а не в рантайме.
S>Частичный — да. На стадии компиляции просто будет принудительно проверяться наличие проверок в оговоренных разработчиком местах.

Не. Ты не понял. На стадии компиляции будет пресикаться любая попытка пораболтать с неинициализированными ссылками. А инициализировать налом будет прсото нельзя.

Но на это, к сожалени, ни Сан, ни МС не решатся. Это будет прямы признанием трех, неоспоримых на мой вгляд, фактов:
1. В МС и Сан проморгали одни из главных граблей и приняли явно безграмотное решение.
2. В МС и Сан не умеют использовать чужой опыт (решение было в МЛ много лет назад).
3. Рантаймы дотнета и Явы содержат охринительные граблищи тупо скопированные с С/С++.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

N>Скоро это изменится.

N>Молчу, молчу... Ребята скоро сами расскажут.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>>2. Ввести в систему типов аналог option[T] (нулабл-типы из дотнета не подходят, так как они применимы исключительно для вэйлью-типов).
EC>Они не решают эту проблему и для value types — меня компилятор не обязывает проверять есть ли значение в обёртке.
EC>Это подходит только для систем типов с алгебраическими типами данных.

Это не так. Решение найти не сложно. Конечно прийдется поменять язык, но это мелочи по сравнению с тем, что прийдется серьезно менять рантайм.

Да и нужны тут не алгеброические типы, а аналог паттерн-матчинга.

В Обероне есть понятие защиты (guard) которое является облегченным аналогом паттерн-матчинга и как раз решает похожие проблемы (безопасного повышающего приведения типов). Можно содрать это решение.

В прочем, введение алгеброических типов было бы действительно отличным решением. Но это, похоже, для МС просто слабо. Для Сана — тоже.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Да и нужны тут не алгеброические типы, а аналог паттерн-матчинга.
Насколько я понимаю паттерн матчинг это процесс обратный конструированию значения алгебраического типа.
Хотя дело даже не в этом. NPE возможен когда у нас есть reference семантика.
Например в Haskell он невозможен потому как там её просто нет (всякие извраты с IORef не в счёт).

now playing: Komputer — Like A Bird

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

E>В языке Nice, работающем поверх JVM, сделали хорошую попытку устранения NPE: http://nice.sourceforge.net/manual.html#optionTypes
Насколько я понимаю это compile only фича. Т.е. с ней происходит нечто аналогичное type erasure generic'ов.
Т.е. JVM об этом ничего не знает. Интересно как выглядит из Java функция с сигнатурой void bar(?String arg).

now playing: Phage & Daniel Dreier — Green Onions

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

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

Это тебе показалось или внушили. На самом деле это некий подход к декомпозиции данных. Конечно АлТД на него ложатся идеально, но и без них он полезен.

EC>Хотя дело даже не в этом. NPE возможен когда у нас есть reference семантика.

Вот в МЛ-языках почти все по ссылке передается. Уж АлТД всегда обязаны по ссылке передаваться. Но проблем нет.

EC>Например в Haskell он невозможен потому как там её просто нет (всякие извраты с IORef не в счёт).

А Хаскеле только она и есть. Причем ссылочность там трехэтажная. Просто нет налов.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>>В языке Nice, работающем поверх JVM, сделали хорошую попытку устранения NPE: http://nice.sourceforge.net/manual.html#optionTypes
EC>Насколько я понимаю это compile only фича. Т.е. с ней происходит нечто аналогичное type erasure generic'ов.
EC>Т.е. JVM об этом ничего не знает.

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

EC>Интересно как выглядит из Java функция с сигнатурой void bar(?String arg).

Я уже давно с Java-инструментами на "вы", так что даже не знаю, как это проверить. Тем более, что у себя Nice я уже снес.

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

VD>Багов будет меньше, так как система типов и язык будут требовать явной обработки для неопределенных значнеий. Будь моя воля я бы вообще запретил в языке явное приведение типов. Оставил бы оное только через паттерн-матчинг:
VD>

VD>match (x : object)
VD>{
VD>    | x is int    => ... // x имеет тип int  
VD>    | x is string => ... // x имеет тип string 
VD>    | _           => ... // тип x другой... неизвестный нам...
VD>}
VD>

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

В Хаскелле сделал

cast :: (Typeable a, Typeable b) => a -> Maybe b

изволь потом матчить Maybe на предмет удачности приведения

Prelude> (cast ’a’) :: Maybe Char
Just ’a’
Prelude> (cast ’a’) :: Maybe Bool
Nothing
Prelude> (cast True) :: Maybe Bool
Just True

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

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

Можешь дать своё определение?
Здесь это определяют как:

Pattern matching is used to test whether things have a desired structure, to find relevant structure, to retrieve the aligning parts, and to substitute the matching part with something else.

Проверка на null это сравнение двух значений, но никак не test whether things have a desired structure.

EC>>Хотя дело даже не в этом. NPE возможен когда у нас есть reference семантика.

VD>Вот в МЛ-языках почти все по ссылке передается. Уж АлТД всегда обязаны по ссылке передаваться. Но проблем нет.

Ты смешиваешь семантику и детали реализации.
То что что-то передаётся посредством указателя ещё не значит, что значения типа имеет ссылочную семантику.
Чтобы обозначить, что значение может отсутствовать используют Maybe, причём само значение типа Maybe не может быть null.
Если бы ссылочная семантика присутствовала, то с чего бы вдруг Maybe понадобился?

VD>А Хаскеле только она и есть. Причем ссылочность там трехэтажная. Просто нет налов.

Можешь пример привести ссылочности в Haskell?

now playing: Phage & Daniel Dreier — Salt And Vinegar

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

E>Имхо, в этом и вся соль. Это как со спецификацией исключений -- компилятор занимается проверками твоих намерений, но не добавляет лишних инструкций в генерируемый код.
Т.е. о checked exceptions JVM ничего не знает?

now playing: Phage & Daniel Dreier — Salt And Vinegar

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

E>>Имхо, в этом и вся соль. Это как со спецификацией исключений -- компилятор занимается проверками твоих намерений, но не добавляет лишних инструкций в генерируемый код.
EC>Т.е. о checked exceptions JVM ничего не знает?

Коллеги говорят, что JVM знает только сигнатуры методов (естественно, что они должны попадать в class-файлы для раздельной компиляции). Но никаких дополнительных проверок в run-time не выполяется.

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

EC>Проверка на null это сравнение двух значений, но никак не test whether things have a desired structure.
Сравнение двух значений это лишь частный случай проверки структуры.

EC>Ты смешиваешь семантику и детали реализации.
EC>То что что-то передаётся посредством указателя ещё не значит, что значения типа имеет ссылочную семантику.
EC>Чтобы обозначить, что значение может отсутствовать используют Maybe, причём само значение типа Maybe не может быть null.
EC>Если бы ссылочная семантика присутствовала, то с чего бы вдруг Maybe понадобился?
Передача по ссылке и возможность присвоить этой ссылке null понятия ортогональные.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

EC>>Ты смешиваешь семантику и детали реализации.
EC>>То что что-то передаётся посредством указателя ещё не значит, что значения типа имеет ссылочную семантику.
EC>>Чтобы обозначить, что значение может отсутствовать используют Maybe, причём само значение типа Maybe не может быть null.
EC>>Если бы ссылочная семантика присутствовала, то с чего бы вдруг Maybe понадобился?
WH>Передача по ссылке и возможность присвоить этой ссылке null понятия ортогональные.
Согласен, только не понял как это относится к процитированному. Не пояснишь?

now playing: Extrawelt & Morelle — Schmedding

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

EC>>>Если бы ссылочная семантика присутствовала, то с чего бы вдруг Maybe понадобился?
WH>>Передача по ссылке и возможность присвоить этой ссылке null понятия ортогональные.
EC>Согласен, только не понял как это относится к процитированному. Не пояснишь?
Так что при наличии ссылочный семантики Maybe нужна.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

now playing: Chloe — Dead End

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

WH>>Так что при наличии ссылочный семантики Maybe нужна.
EC>Только если значения Maybe имеют value семантику или есть статическая гарантия, что они не могут быть null, что в контексте этого обсуждения одно и тоже.
Совершенно не одно и тоже.

class Test
{
    public int i = 0;
}

...
Test t1 = new Test();
Test t2 = t1;
t1.i = 1;
Console.WriteLine(t2.i);

Данный код напечатает 1.
Если class заменить на struct то этот код напечатает 0.
В этом разница между значениями и ссылками.
И это ни коем образом не относится к возможности присвоить ссылке null.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

WH>В этом разница между значениями и ссылками.
Это и так понятно.
WH>И это ни коем образом не относится к возможности присвоить ссылке null.
Я так и не понял тебя.
Зачем нужен Maybe при наличии ссылочный семантики?
Вот зачем нужен Nullable<T> where T struct мне понятно и понятно зачем там констрейнт.
Но зачем он может понадобиться для ссылочных типов не могу придумать.
Или ты имеешь в виду, что есть 2 варианта ссылок: nullable & nonnullable?

now playing: Super Flu — Tripple Mapple

Здравствуйте, VladD2, Вы писали:
VD>Дык, а зачем вообще исключения когда можно остановить проблему в зародыше (при компиляции)?
Мир несовершенен. Тебе один хрен может прийти null "снаружи" — ведь не весь код написан на новой технологии. Да и внутри твоей программы могут понадобиться опциональные значения. Заметь, во второй шарп ввели Nullable типы ровно для тех, у которых нулла вовсе не было. Значит — есть спрос!
Там, где я явно написал int?, я подразумеваю возможность отсутствия значения. И именно приведения int? к int будут выкидывать исключения.
VD>Не. Ты не понял. На стадии компиляции будет пресикаться любая попытка пораболтать с неинициализированными ссылками. А инициализировать налом будет прсото нельзя.
Я всё прекрасно понял.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

D>В Хаскелле сделал
...
D>изволь потом матчить Maybe на предмет удачности приведения

Что мне помешает написать

toChar :: a -> Char
toChar = fromJust . cast

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

VD>>Это тебе показалось или внушили. На самом деле это некий подход к декомпозиции данных. Конечно АлТД на него ложатся идеально, но и без них он полезен.
EC>

EC>Можешь дать своё определение?
EC>Здесь это определяют как:
EC>

EC>Pattern matching is used to test whether things have a desired structure, to find relevant structure, to retrieve the aligning parts, and to substitute the matching part with something else.

EC>Проверка на null это сравнение двух значений, но никак не test whether things have a desired structure.

Сори... Глядим в книгу — видеим фигу? Где в приведенной цитате хоть слово про АлТД? Мое утверждение только об этом.

EC>>>Хотя дело даже не в этом. NPE возможен когда у нас есть reference семантика.

VD>>Вот в МЛ-языках почти все по ссылке передается. Уж АлТД всегда обязаны по ссылке передаваться. Но проблем нет.

EC>Ты смешиваешь семантику и детали реализации.

Ага. Меня вообще не трогают вакуумные сфероконики.

EC>То что что-то передаётся посредством указателя ещё не значит, что значения типа имеет ссылочную семантику.

А меня не трогают заумности. Если указатель есть, то и тормоза от доступа по нему будут.

EC>Чтобы обозначить, что значение может отсутствовать используют Maybe, причём само значение типа Maybe не может быть null.
EC>Если бы ссылочная семантика присутствовала, то с чего бы вдруг Maybe понадобился?

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

VD>>А Хаскеле только она и есть. Причем ссылочность там трехэтажная. Просто нет налов.

EC>Можешь пример привести ссылочности в Haskell?

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>А меня не трогают заумности.
Где ты там заумность увидел?
Вообще странно такое слышать от человека участвующего в разработке компилятора

VD>Если указатель есть, то и тормоза от доступа по нему будут.
Неужели? Т.е. передача структуры по ссылке в .NET это тормоза?
Это как минимум не медленнее чем передавать её по значению.
Или там указатель не используется?

EC>>Можешь пример привести ссылочности в Haskell?

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

now playing: Elvis Presley vs Richie Hawtin & Guido Schneider — Visual Idols Edit

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

S>Очень странно. Nullable<int> — это ровно тот же option[int], вид сбоку.

Отнюдь.

S>Есть два способа привести от int? к int: безопасный и небезопасный.

Дык, а способов привести option[T] к T существовать не должно. Вообще!

В общем, проще перечислить различия:
1. При использовании option[T] тип T может быть любым (в том числе ссылочным и option[Х]). Тип T? может быть только вэлью-типом.
2. Не должно существовать способов обратиться к значению T кроме как специального защищающего оператора вроде match (паттерн-матчинга) или guards (из оберона).

S>Вот безопасный метод в более похожем на Nemerle стиле:
S>

S>int? n = null;
S>int a = n ?? 0;
S>

А если нет приемлемого значения по умолчанию или просто неохота с ним связываться?

Оперто ?? конечно хорош, но хорошо бы иметь возможность сделать так:

match (n)
{
  | Some(x) => исполььзуем значение ищ n (теперь оно доступно через x)
  | None    => делаем что-то в случае если n не содержит значения (или ничего не делаем).
}

S>Чего не хватает в дотнете — это обратной штуки для reference-типов. Точнее, ее можно сделать самому, но без поддержки со стороны компилятора ее полезность близка к нулю.

Да не должно быть разницы для ссылочных типов. Просто option[T] обязан допускать любой T, без ограничений. И именно по этому те кто делали нулабл-вэлью — уроды. Сколько раз я нарывался на то, что немогу написать простой обобщенной функции только из-за этого ограничения?!

S>Я склонен согласиться, что имело бы смысл и для референс типов сделать non-nullable тип основным, а возможность использовать null нужно было бы указывать явно.

Вот именно. И тода уж можно было бы вообще забыть про само понятие null, заменив его понятием необязательного значения.

S>Влад, я всё уже прочитал и понял.

Замечательно.

ЗЫ

Вообще, создатели современных мэйнстрим-языков очень зря "пропустили мимо ушей" некоторые решения из функционального мира. Функциональные типы, option-значения, паттерн-матчинг, аглеброические типы — это то, что обязательно надо ввести в ЯП, чтобы он был современным. Очень жать, что они понимают это слишком поздно. Это приводит к грязным решениям. Такие фичи нужно учитывать при проектировании ЯП и рантаймов.

От:	mkizub	http://symade.tigris.org
Дата:	29.08.07 09:56
Оценка:	1 (1) +3 -2

	От:	WolfHound
	Дата:	29.08.07 19:37
	Оценка:	2 (2) +1

	От:	Klapaucius
	Дата:	30.08.07 16:59
	Оценка:	+3

От:	_Obelisk_	http://www.ibm.com
Дата:	29.08.07 09:58
Оценка:	4 (2)

От:	eao197	http://eao197.blogspot.com
Дата:	31.08.07 04:26
Оценка:	+1

От:	IT	linq2db.com
Дата:	29.08.07 20:20
Оценка:	6 (2) +1

От:	VladD2	www.nemerle.org
Дата:	06.09.07 10:30
Оценка:	12 (3) +1

От:	nikov	http://www.linkedin.com/in/nikov
Дата:	29.08.07 10:08
Оценка:

	От:	BulatZiganshin
	Дата:	29.08.07 18:13
	Оценка:	+1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	06.09.07 13:39
Оценка:	+1

От:	Sinclair	https://github.com/evilguest/
Дата:	12.09.07 12:56
Оценка:	+1

От:	Стэн	http://stanonwork.blogspot.com/
Дата:	30.08.07 17:56
Оценка:

От:	rsn81	http://rsn81.wordpress.com
Дата:	30.08.07 18:52
Оценка:

От:	Курилка	http://kirya.narod.ru/
Дата:	31.08.07 05:57
Оценка:

	От:	Константин Л.
	Дата:	31.08.07 20:28
	Оценка:

	От:	MatFiz
	Дата:	01.09.07 08:01
	Оценка:	+1 -3

	От:	Left2
	Дата:	03.09.07 08:10
	Оценка:	+1

От:	lomeo	http://lomeo.livejournal.com/
Дата:	12.09.07 09:38
Оценка: