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

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

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

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

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

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

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

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

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

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

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

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

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

MihalNik

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

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

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

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

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

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

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