БК-0010 старца

[Fouras]

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

Неправильно ты понимаешь.

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

Давай уточним, не было ли это так:
Программисты разрабатывают программы. Иногда используют диаграммы классов, состояний, информационные и idef-0. И перед сдачей приемка замечает, что не хватает блок схем. Им замечают:
- Вы же понимаете, что у нас более 200 мегабайт текстов суммарно по проектам и не менее 30 по данному, не существует человека, который сможет просмотреть все блок схемы по этому коду, даже если мы его создадим?
- Мы понимаем, но существуют требования по программной документации.
- Ок, вы хотели этого, вы это получите.

За три дня рисуются какие-то квадратики и ромбики на отъ@бись, делается описание с указанием, что это ключевые алгоритмы.

Предположу, что ты наблюдал эту ситуацию не со стороны программиста, и по-своему истолковал.

[Fouras]

О, какой замес пошел))

Немного неловко даже теперь спрашивать, но что вы среди всего этого о Python думаете?

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

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

[Eiffel]

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

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

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

Господи, на какой же бред, куда намешано вообще все и вся, я отвечаю. Это помимо того, что в нем речь идет не о техническом различии двух подходов (кроме момента, что его толком нет, что неправда), о котором спрашивалось, а об истоках, и то -- неверно...

[Eiffel]

Насчет блок-схем со Старцом соглашусь, если речь шла именно о ГОСТ-овском языке блок-схем. Он абсолютно ничтожен, полностью императивен и по сути годится только для описания алгоритмов во времена машинных языков, до появления даже первых ассемблеров с нормальными комментариями. Он не охватывает ни ООП, ни декларативное программирование. Ну и, вообще говоря, чисто чернологичен, так как представляет собой описание последовательности действий во времени, а не статичную разветвленную структуру.
Т.е. им НЕ опишешь последнюю, им нельзя в принципе описать устройство чего-то, а только лишь шаги во времени. Поэтому он уже не БЛен.
--
Если речь шла именно о структурировании как таковом (тогда непонятно описание на равных некого ЯБС и UML) -- естественно, оно нужно, и любому программисту, как ЧЛ, так и БЛ, хотя для БЛ оно более родное.
--
Вообще, сорри за оффтоп, рассуждая чисто по семантике языков:
- декларативные языки -- статика, БЛ, причем ближе таки к связке с ЧИ. Маккарти был ЛИИ, скорее всего...;
- ассемблерные языки и Фортран -- по природе своей чистая ЧЛ, но само описание языка и понимание архитектуры, для которой пишешь, обычно ближе к БЛ;
- С -- смешанный язык. С одной стороны, там ЧЛ от предыдущих, но больше БЛ в силу появления структурированности языка (но без возможности описания вложенных процедур, которая, правда, обычно нафиг и не нужна). И там еще и хватает много ЧИ и изощренной многовариативности, до которой надо еще додуматься (то, что часто понимают под гибкостью С) -- это в силу самого типа Ритчи, это не черта процедурных языков как таковых;
- ООП-подход -- сам по себе был описан с позиций статичной БЛ, хоть и неформально, потом скатилось во все и вся.

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

[mr.Midas]

О, какой замес пошел))

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

[Eiffel]

Забавна кстати ситуация, когда ЛСЭ-завкафедры и главный оцениватель дипломов по совместительству на защите требовал полного соответствия ГОСТу (именно вот тому самому ) в работах учащихся, в частности, в моем дипломе по простой ОС, так как это, типа как (с серьезным лицом, типа отрицание автоматически обозначает полное отсутствие первого и сразу бездумное кодирование), "первый шаг перед кодированием, дающий понимание, а уже потом идет кодирование".
Я ему старался втолковать, что с уровнем детализации ГОСТа физически сложно описать некий "алгоритм ОС" (можно на более высоком уровне, в принципе, но все равно кривовато получится, так как рассчитан то ГОСТ был не на это, а именно на детальные шажки), и что лучше просто использовать разного рода более подходящие высокоуровневые собственные рисунки и диаграммы. Не помогло... Ну, что ж, вставил высокоуровневый, а для деталей -- только для загрузчика.
Жертва советстких стереотипов месье был, что сказать (ну или не писал ничего сложнее сортировки, и там -- вставками).

[mr.Midas]

Причем проекты эти реально внедрялись.

Я говорю именно о внедрении разработки с нуля, когда даже среда разработки неизвестна. И да, мне для ТЗ приходилось их рисовать (с разной степенью детализации/проработки) и согласовывать с заказчиком только уже для того, что бы определиться с языком проекта и обосновать стоимость сопровождения. Конечно можно держать свой штат спецов и тогда плевать на клиентов. Но это не мой случай т.к. это уже корпоративный уровень. Можно повесить специализация на своих программеров, что часто встречается у финансовых разрабов. Но когда берешь в руки тот же склад от 1С и видишь что его делали ... , опираясь именно на программную среду, а не нормальную проектную автоматизацию... В общем не хочется мне снова ворошить этот доткомовский булшит а'ля agile etc
Так что на моём, весьма средненьком, шестке или приглашался спец со стороны или работали со спецами заказчика. Второе чаще. У меня классическое образование с опорой на ЯБС и поэтому мне проще было освоить ещё один ЯП, чем стать химиком-технологом или мастером механического участка что бы адекватно описывать объект.

[mr.Midas]

Я ему старался втолковать, что с уровнем детализации ГОСТа физически сложно описать некий "алгоритм ОС"

Ты уверен, что ты говоришь о ГОСТЕ?

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

[Eiffel]

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

[mr.Midas]

И см. мое дополнение в скобках

Так в скобках-то самое не понятное. Размер шажка ты сам определяешь в нужном месте и по своим задачам. Интересно у тебя черчение было как предмет? Что такое проекция по секущей встречал?

[Eiffel]

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

[mr.Midas]

но что вы среди всего этого о Python думаете?

А он тебе для чего нужен? Если как финансовый инструмент то это одно, а если для самореализации...

[Fouras]

\У меня классическое образование с опорой на ЯБС и поэтому мне проще было освоить ещё один ЯП, чем стать химиком-технологом или мастером механического участка что бы адекватно описывать объект.

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

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

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

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

Я рисовал однажды. Был выделенный проект: создать чисто софтварную систему 3D визуализации на некоторую специфическую платформу, крайне слабую. Работа на одного человека. Ок, сделал. Теперь пиши документацию. И тут эти квадратики-ромбики вылезли. И как ими описывать взаимодействие объектов с перегруженными функциями? Никак. Они же могут описать только элементарные последовательные алгоритмы.

[Nafeyhoa]

но что вы среди всего этого о Python думаете?

А он тебе для чего нужен? Если как финансовый инструмент то это одно, а если для самореализации...

Теперь скорее всего уже незачем, хотя любопытен, мне кажется его можно даже детишкам показывать, самое простое. Там нет вначале никаких подключений библиотек, и прочих конструкций, вызывающих вопросы "а что это вообще такое?"
Искала язык для начала (ну, когда-то мы все в школе изучали Бэйсик, на этом всё), и вот когда задумывалась о нем, как ни крути это получался язык для учёбы, накой он дальше я так и не поняла, хотя пыталась. Лишь упомниание что его используют Гугл и ряд компаний (насколько реально широко используют?...) и общее впечатление - что в основном его используют всякие Линуксоиды, в преимущественно некоммерческом ПО) То есть его перспективность и востребованность так и осталась в тумане. С Java, С++ и прочими всё же более ясная картина.

[Буран]

Питон используют много где, в том числе и в коммерческом ПО. Вроде бы, он входит в первую десятку ЯП по популярности.

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

Можно начинать изучение с него, просто надо чётко представлять, что будешь изучать дальше. Питон из того семейства языков, в которое входит Perl, PHP и (с большой-большой натяжкой) JavaScript. А Java - из того же семейства, что C++, C#, Objective-C. Pascal тоже к ним близок.