Ремесло программиста

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Ремесло программиста » Общие вопросы по языкам программирования » Почему сторонники жёсткой типизации выбирают одиночную разработку.


Почему сторонники жёсткой типизации выбирают одиночную разработку.

Сообщений 1 страница 30 из 37

1

При гибкой типизации любая функция представляет собой интерфейсвзаимодействие в свободном виде, а при жёсткой - нет, откуда
усложнение в самораспределении работ.

2

Ничего не понял. Нужно было раскрыть тему многословнее.

Итак, типизация по-вашему бывает "жёсткая" и "гибкая". Это единственное, что удалось понять.

Программисты приверженные  жёсткой типизации усложняют себе работы. Ну да, потому что жесткая типизация даёт им преимущества (при расппонтовках они могут вытащить её из ... и положить на стол. Мол: "у нас типизация о-го-го, а у вас - нет".

А выбирают одиночную разработку - неясно почему. Можно пофантазировать, что это из-за того, что такие программисты - приверженцы высоких идеалов (причём у каждого эти идеалы - разные, а по-этому не позволяют объединиться в команду).

Но это фантазии, а хотелось бы услышать версию топикстартера (он ещё, кстати, план свой не озвучил).

3

Давайте обсудим общие интерфейсы и сможем двигаться дальше.
К примеру как насчёт использование DWARF, как формат БД для отладочных символов и прочего?

Отредактировано Павиа (2017-04-10 20:54:38)

4

Павиа написал(а):

Давайте обсудим общие интерфейсы и сможем двигаться дальше

никаких переговоров с террористами.

Вам, Павиа, сначала надо изучить основы этики и научиться начинать новые ветки, чтобы не плодить оффтопик.

Павиа написал(а):

К примеру как насчёт использование DWARF, как формат БД для отладочных символов и прочего?

в системе, основанной на фрактальном отращивании (ака Кантор) отладочная информация является органической частью (несущей) структуры.
Поэтому внешние подпорки и костыли типа БД символов не нужны.

Отредактировано Лис (2017-04-10 22:12:04)

5

Лис

Офтотопик

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

6

Павиа написал(а):

все вокруг террористы


Ну почему же все? На этом форуме пока именно и только Вы.
MihalNik, например, меня разумно игнорирует.

7

Сандро написал(а):

Посмотрите на Лиса, насколько он спокоен и рационален на собственном форуме - то же самое происходит и с другими.

Лис предлагает проехаться пятой точкой по всем существующим граблям=)

8

Таки-да,.. Это как сравнивать собственный, "частный" дом с общагой. В общаке - вечные потасовки, по поводу и без, тогда как собственник - более степенен и самостоятелен. У него нет ни времени, ни желания пустословить вне дела. Я обожаю читать Лиса на его форуме. Всё по делу. - Даже юмор... )))
- А теперь давайте про типизацию... Чё за "зверь" и каким местом разобщает коллективное творчество...
У нас до сих пор не появился талантливый "распределятор" ролей, он же идейный организатор, некий аналог Паронджанова, коего уважают даже ярые противники...

9

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

Сандро написал(а):

не появился талантливый "распределятор" ролей

В свободных сообществах роли не распределяют, а ставят и берут на себя задачи.

10

MihalNik написал(а):

В свободных сообществах роли не распределяют, а ставят и берут на себя задачи.

В свободной типизации роли не ставя, а берут на себя. ;)

11

Правильно!

MihalNik написал(а):

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

12

MihalNik
Любая программа это система.Система совокупность элементов на которые наложены связи.
Как не крути, а связей у системы меньше не станет.
Вот к примеру такую программу как "компилятор", как вы предлагаете разбить на типы?

13

Павиа написал(а):

MihalNik
Любая программа это система.Система совокупность элементов на которые наложены связи.
Как не крути, а связей у системы меньше не станет.

Но связей легко может стать больше чем нужно.

Павиа написал(а):

Вот к примеру такую программу как "компилятор", как вы предлагаете разбить на типы?

В языке вроде делфи - расширениями от общего класса (узла дерева/списка/стека) несущего внутреннего представления программы.

14

MihalNik

MihalNik написал(а):

В языке вроде делфи - расширениями от общего класса (узла дерева/списка/стека) несущего внутреннего представления программы.

Не понимаю. И где здесь мягкая типизация? Хотелось бы развёрнутый ответ с наглядными примерами.

Есть набор знаков мы его преобразовали в набор лексем.  Затеем перевели в синтаксическое дерево. Делаем его вывод для отладки.
Но вот засада комментарии не подчиняются семантики. Как с ними быть? Хотелось бы их восстановить.
Следующая стадия семантический анализ. Надо заменить одноименные идентификаторами общими связями. Получается семантический граф. Который по своей природе похож на дерево. Корень в верху листва внизу. Причём вначале приходиться идти вверх к корню дерева, ища объявления функций, а потом уже идти вниз  по параметрам, локальным переменным.
Затем следующая стадия, проставляем типы операторов.
Так вот на стадии семантического анализа можно выявить ошибки. Не верное число параметров передаётся в функцию. Или в условном оператор целый тип вместо логического.
Так вот хочется выводить эти ошибки что-бы пользователь знал где она произошла. Приходиться хранит для каждого узла дерева/графа его позицию в файле. Приходится сохранять структуру для лексем. Да и для отладочной информации нужен номер строки.
А потом при переводе на ассемблер появляется словарик. Так как у ассемблера свои служебные слова у вашего языка свои. Ваш язык поддерживает вложенные переменные ассемблер нет.
Или EXE-PE есть правила по кодированию имён экспортируемых и импортируемых функций и переменных.
Причём словарик для языка такого как паскаль должен различать типы идентификаторов. И самый простой способ хранить ссылку на семантическое описание объекта, что-бы была возможность однозначно идентифицировать хозяина.

Отредактировано Павиа (2017-06-26 10:21:20)

15

Но связей легко может стать больше чем нужно.

Строго говоря доказательства того, что это ухудшит систему нет. Интуитивно понятно - что чем больше связей, тем сложней понимать систему. Но это не аксиома. если связи однотипны и предсказуемы, подчиняются одной закономерности, то проблем нет.  Беда в том, что нет формальной оценки сложности систем, так как ее разработка определяется разработчиком - то есть изначально это не формальный и не просчитываемый процесс.  Есть отдельно рассмотренные классы систем, по которым можно предсказать сложность разработки, но это не все возможные варианты. Нельзя утверждать, что в каком-то конкретном случае сторонний разработчик не может предложить какую-то суперорганизацию, которая будет проста и понятна. Аналогом является легенда о Гордиевом узле, когда чувак не стал развязывать веревку, а просто отрезал ее мечом и тем самым вписал себя в историю. Это касается даже всяких банальностей. Вроде вот сортировки например, исследованы и практически и математически. Но нет ни одного исследования, которое бы доказало, что не существует некой неизвестной сортировки, которая возьмет и побьет любую сортировку по всем параметрам за счет какого-нибудь жутко заверченного алгоритма, основанного на рекурсии (то есть много связей, но один принцип).

В языке вроде делфи - расширениями от общего класса (узла дерева/списка/стека) несущего внутреннего представления программы.

Мой скромный опыт подсказывает одновременное использование и обратных тенденций - сначала проектировать независимые отдельные компоненты, а потом их уже включать в общее. Простое расширение ведет к неконтролируемому хаосу (и трансу :) ).

Но вот засада комментарии не подчиняются семантики. Как с ними быть? Хотелось бы их восстановить.

Включить их в семантику. Что такое комментарий? Это операция перехода на следующую строку программы :). Я сам при проектировании не рассматриваю комментарии как часть программы :), они выкидываются на стадии формировании лексем. В моей модели мне так приятней :)

А потом при переводе на ассемблер появляется словарик. Так как у ассемблера свои служебные слова у вашего языка свои. Ваш язык поддерживает вложенные переменные ассемблер нет.

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

16

utkin написал(а):

Беда в том, что нет формальной оценки сложности систем, так как ее разработка определяется разработчиком - то есть изначально это не формальный и не просчитываемый процесс.

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

utkin написал(а):

Мой скромный опыт подсказывает одновременное использование и обратных тенденций - сначала проектировать независимые отдельные компоненты, а потом их уже включать в общее. Простое расширение ведет к неконтролируемому хаосу (и трансу  ).

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

Павиа написал(а):

Так как у ассемблера свои служебные слова у вашего языка свои. Ваш язык поддерживает вложенные переменные ассемблер нет.

Непонятно про какой язык речь. Про входной?

Павиа написал(а):

И где здесь мягкая типизация?

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

Павиа написал(а):

вывод для отладки.

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

Павиа написал(а):

Но вот засада комментарии не подчиняются семантики. Как с ними быть? Хотелось бы их восстановить.

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

Павиа написал(а):

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

Можно сохранить номера строк вместе с лексемами. А в узлах дерева хранить ссылки на лексемы.

17

Формальная оценка есть - называется классом задач.

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

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

Есть мнение, что существуют алгоритмы (типа криптографии), что пока я буду вручную перебирать, мои правнуки изобретут более совершенный аппарат и переберут быстрей.

И я видел код в В-1 - да, там был хаос=) и он же вроде при этом ещё и работал=)

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

Непонятно про какой язык речь. Про входной?

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

Вообще же можно максимально обобщить типы, выбрав самый широкий, например, вместо целочисленной арифметики - [временно] вещественная, или реализация всех типов строками (в В-1 числа строковые, хоть там интерпретатор, но сути это не меняет).

Тип на основе которого строятся другие называется базовый тип данных. В В-1 числа в строках потому что я мечтал о полнофункциональной длинной арифметике. Большинство длинных типов заточено под целые длинные числа. Я все хотел на длинной арифметике. 

Можно сохранить номера строк вместе с лексемами. А в узлах дерева хранить ссылки на лексемы.

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

18

utkin написал(а):

Класс задач это адаптация проблемы к машине Тьюринга, а не определение сложности проблемы

Нет. Машина Тьюринга используется только для определения частного класса задач и там это тоже связано со сложностью.
Класс задач - это просто общее понятие.

utkin написал(а):

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

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

utkin написал(а):

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

Для ряда алгоритмов и конкретных машинных архитектур можно построить нижнюю оценку.

utkin написал(а):

Есть мнение, что существуют алгоритмы (типа криптографии), что пока я буду вручную перебирать, мои правнуки изобретут более совершенный аппарат и переберут быстрей.

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

utkin написал(а):

Я не соблюдал правила именования, форматирования и пр. Эти ошибки не про процедурное программирование, а про программирование больших и сложных систем. Для объектов и классов это все тоже в полной мере относится.

Я это и подразумевал. Если бы там были ошибки в коде, оно бы не работало=) Но сам код плохо читаем. При увеличении сложности можно потерять контроль.

utkin написал(а):

Тип на основе которого строятся другие называется базовый тип данных. В В-1 числа в строках потому что я мечтал о полнофункциональной длинной арифметике. Большинство длинных типов заточено под целые длинные числа. Я все хотел на длинной арифметике.

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

utkin написал(а):

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

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

Про числа в теме про калькулятор

19

MihalNik написал(а):

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

Так покажите пример где есть гибкость, от мягкой типизации.

20

Павиа написал(а):

Так покажите пример где есть гибкость, от мягкой типизации.

Не понятно, пример чего из 7 перечисленных вариантов Вы хотите увидеть.
Компилятора на языке с утиной типизацией? Х.з., наверное, есть такие.
Утиная типизация - Вы добавляете в класс новые методы и разработчикам библиотеки, использующей ранее существующие методы,  не надо ничего у себя менять. И пользователям этой библиотеки в связи с ней не надо, при этом они могут спокойно воспользоваться новыми методами класса.
В итоге можно написать часть ядра, необходимую для библиотеки и, перепоручив её разработку, продолжить делать ядро, не отвлекаясь на техническую поддержку зависимостей.
Или нет там такого идеологического препятствия, как неработающая местами программа - можно прерваться на половине новой функции, сделать поправку в старой и сразу же раздать обновление вместе с этой написанной на половину. Вы понимаете, насколько технически проще организация совместной работы?

21

MihalNik написал(а):

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

В Delphi с этим нет проблем, до здравствует COM.
http://www.gunsmoker.ru/2011/12/delphi.html

MihalNik написал(а):

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

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

Отредактировано Павиа (2017-06-28 10:30:34)

22

Павиа написал(а):

В Delphi с этим нет проблем, до здравствует COM.

В Excel делать многие расчёты быстрее, потому что существует быстрая обратная связь -
любая отдельная функция в ячейке - сразу выполняется - независимо от того, что где-то в других м.б. ошибки.
А теперь тут для словарей выбрали гугл-таблицы, всё перетекает в гибкий JS из менее гибкого VBA.

Поэтому существует интеграционное тестирование.

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

Павиа написал(а):

А потом другой разработчик будет чесать репу почему у него не работает когда проблема у коллеге который бросил функцию на половине.

Для этого вначале пишутся проверки, а потом - сама функция. Поэтому будет сразу написано, что не рабочая.

Важно технически насколько просто или сложно создать организованность действий.
Статичная проверка требует намного больших расчётов, намного более сложного ПО и действий в каждом случае.
Поэтому гибкая типизация позволяет легко проверять раздельно каждую функцию или любое подмножество, а жёсткая - с большим трудом.

Пытаться объяснить в 2-х словах бессмысленно, это нужно самостоятельно проводить опыты, почитав что-нибудь для начала, например, вроде "Разработки через тестирование"  К.Бека и "Рефакторинга" Фаулера, потом сравнив управление проверками в Java и Python на кол-во телодвижений.

23

Эти книги я читал.

MihalNik написал(а):

в Java и Python на кол-во телодвижений.

Это два моих нелюбимых языка. Поэтому не знаю не первый, не второй.

24

Павиа написал(а):

Эти книги я читал.

Это два моих нелюбимых языка. Поэтому не знаю не первый, не второй.

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

25

MihalNik написал(а):

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

- Да лехко... Я этих книг перечёл - тьма, (не "аглицких" конечно))), а практики - не было, вот и результат: все "аглицкие" языки - нелюбимы мной...  Это состояние - неописуемо; ничего не имею против самих иностранцев, а вот на их письменность не могу смотреть без "содрогания"... Отторжение - полнейшее. В школе все предметы знал на отлёт, кроме буржуйского "аглицкого". Меня училка на ключ в классе запирала после уроков, чтоб не сбежал, пока не выучу, тем самым ещё более укрепляя отвращение к этому языку...

26

Это два моих нелюбимых языка. Поэтому не знаю не первый, не второй.

Очень зря. Ладно Джава бюрократическая система, в Питоне много абстрактных типов данных облегчающих программирование. Правда методика его использования порочна - его часто используют как Бейсик. Питон так-то гибче в том плане, что написать на нем что-то сложное проще чем на Джаве. Но вот отсюда эта излишняя демократия приводит потом к тому что многие при написании кода не следят за всякими там правилами именования и пр. Переменные в одну букву нормальное явление, при том что там может быть портянка кода с большим количеством функций, а сами переменные могут содержать ссылки на сложные структуры. Плюс еще одна проблема - питонцы страшно не любят комментарии - автор Питона сторонник того, что программы на Питоне и так отлично читаются. Поэтому Питон легче Джавы в плане написания каких-то плюшек, но это часто приводит к расхлябанности питонистов. Знаю потому что одно время мне приходилось перелопачивать много программок на Питоне для сравнения алгоритмов, написанных разными авторами. В целом Питон вызывает ностальгию по Бейсику. Конечно не проблема языка, что люди не умеют использовать некоторые правила программирования, но в целом философия Питона располагает к этому. Что касается Джавы, то она многословна и бюрократична - программист должен максимально облегчать работу компилятора, но учитывая сферу применения это наверно оправдано. Многие большие и сложные вещи написаны с использованием Джавы. Например, казначейская система СУФД, а это система уровня страны между прочим. Поэтому вопрос что лучше мягкая типизация или жесткая тут сложный. С одной стороны Питон это весело и просто с другой стороны Джава это серьезный бизнес  :glasses:

27

utkin написал(а):

многие при написании кода не следят за всякими там правилами именования и пр.

Просто многие новички в программировании начинают с Питона и программы написанные ими соответствующего качества. В Делфи была та же проблема, да и сама же навязывает плохие имена, так что это зависит лишь от культуры среды разработки и собрания чужих исходников - нужны определённые требования. В типизированных языках культура наименования часто ниже - включение типов в имя, венгерский и финикийский. У нас на форумах два ярких таких примера, при том все говорят, что непонятно написанное, требуют комментариев, а, спрашивается, зачем так плохо писать?
В В-1 была обратная проблема - код слишком многословен для довольно гибкого языка из-за чего размыта видимость единиц трансляции.
Т.е. нужна какая-то мера - правила соотнесения м/у естественных языком и программным кодом, иначе становится сложно.

Питон легче Джавы в плане написания каких-то плюшек, но это часто приводит к расхлябанности питонистов.

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

utkin написал(а):

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

Это плата за жёсткую типизацию. Сложность контроля заставляет делать по нескольку обёрточных уровней, из-за чего теряется даже значительная часть начального быстродействия таких языков. Всё тоже самое требуется в Делфи, чтобы создавать программы подобного уровня, хотя там намного проще с портянками и двоичный уровень не обгрызан.
Можно писать в стиле Питона на всех языках, включая ту же Java, но корпоративная среда - медленная и ленивая.

Знание python|java конкретно для темы не важно.
Можно сравнить трудоёмкость организации коллективной разработки в Делфи/FreePascal и PHP или какой-нибудь другой пары.

28

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

Ну вот она бейсиковость :).

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

С этим беда вообще. Определить можно только в результате экспериментов с текущим набором параметров (языком, опытом применения в определенной сфере и т.д.). Но я пришел к идеи сменяемого синтаксиса! В моем позднем творчестве это четко выражено :). Последняя модификация первой Валентины умела менять синтаксис. Правда она писалась на 7-й Делфи, а там с юникодом беда. Тогда это побудило меня искать новые инструменты и я хотел потом c#. Поэтому каждый может выбрать - короткий синтаксис из спецзнаков а-ля Хаскелл или многословный Кобол :). У меня и подобие инфраструктуры было - редактор (туповатый и примитивный) для написания своих конструкций и генерация отчета по синтаксису в форме близкой к БНФ.

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

Каждая переменная с плавающим типом это источник ошибок и безобразия. И если в первом случае корректность определяется автором системы, то тут никаких гарантий нет в принципе. А вот где найти ту грань, которая бы решала оба этих вопроса? Тесты тоже не решают проблемы, ведь если программу можно верифицировать тестом, то чем можно верифицировать тест? Если функция возвращает сложный объект, как проверить его корректность? И кто будет проверять корректность проверки? Эта рекурсия становится актуальной для сложных информационных систем.

29

https://habrahabr.ru/post/114981/

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

30

ВежливыйЛис написал(а):

Подход C/C++ совсем другой.

Подход С/С++ это бесконечная техподдержка. И наигравшись с дырявой логикой большинство с облегчением сваливают на Java, C# и пр. или делают всякие библиотеки для них. Потому что интерфейс на каком-нибудь Python востребованее.

ВежливыйЛис написал(а):

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

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


Вы здесь » Ремесло программиста » Общие вопросы по языкам программирования » Почему сторонники жёсткой типизации выбирают одиночную разработку.