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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я просто очень большой ребенок А любимые игрушки -- велосипеды

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

С>Скорее дел в том, что в 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 два конструктора с параметрами, то вызов какого из них будет сделан за программиста?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 так понравился... ты просто не писал никогда сложных программ, не участвовал в сложных проектах.

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

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

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

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

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

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

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