Программирование

[Kornelia]

Из того, что тогда было, сейчас только от Си с Бейсиком польза. Но его изучали отдельно. Тогда и вместо Паскаля был Алгол-60.

А всё остальное почти не использовалось.

От вуза навряд ли что зависит, постепенно всему можно научиться и самому.

Если есть основы: один язык из императивного программирование, то всё остальные императивные языки - дело не только наживное самостоятельно, но и быстро наживное самостоятельно. Хотя соглашусь с тем, что этого добиться можно и без университета.
Ну, и ровно также с объектно-ориентированным и функциональным программированием.

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

Ну, и плюс стандартное образование даёт некоторую "стандартизацию" в методах и стиле написания софта. Потому что "нестандартные" гении - это круто, красиво и замечательно. Но лишь до тех пор пока не поваришься пару лет в больших проектах (около 100, а то и 200 человек, в течение 1-2 лет), когда все кусочки нужно сводить воедино, а потом стиль написанного должен был таким, чтобы те, кто после нас, лет через 5 лет, станут наш софт переделывать под изменившиеся требования, могли относительно легко разобраться...

 

[aeg]

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

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

А надо вот как. Сделать тематические отделы, которые будут составлять алгоритмы, и программистские, которые будут по ним программировать. Отдельно должны быть люди, которые всё это документируют.

У нас же все занимаются сразу всем.

Ну, и плюс стандартное образование даёт некоторую "стандартизацию" в методах и стиле написания софта. Потому что "нестандартные" гении - это круто, красиво и замечательно. Но лишь до тех пор пока не поваришься пару лет в больших проектах (около 100, а то и 200 человек, в течение 1-2 лет), когда все кусочки нужно сводить воедино, а потом стиль написанного должен был таким, чтобы те, кто после нас, лет через 5 лет, станут наш софт переделывать под изменившиеся требования, могли относительно легко разобраться...

В реальности быстрее переписать заново, чем разобраться и модифицировать. Как вариант - сделать над тем, что есть, обёртку и добавить что-то новое.

Невозможно заранее угадать все расширения, которые потребуются в будущем.

 

[Kornelia]

У нас же все занимаются сразу всем.

Я не могу судить по личному опыту как у Вас, так как мой опыт ограничивается Германией/Швейцарией/Бельгией. С учётом того, что в него входят (я была занята проектной работой в техническом консалтинге): SAP (Waldorf), Siemens, Accenture, немецкая железная дорога, пара фирм из энергетики (вот уж кто ни разу не жадина, между нами говоря) и т.д., то кое-что я видела. Но ни разу, ни разу я не видела на практике:

А надо вот как. Сделать тематические отделы, которые будут составлять алгоритмы, и программистские, которые будут по ним программировать. Отдельно должны быть люди, которые всё это документируют.

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

В реальности быстрее переписать заново, чем разобраться и модифицировать. Как вариант - сделать над тем, что есть, обёртку и добавить что-то новое.

Господь с Вами! Переписать заново то над чем 100 человек в течении года работали? Разоритесь быстро.

Невозможно заранее угадать все расширения, которые потребуются в будущем.

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

 

[aeg]

В смысле, не видела, чтобы алгоритмы разрабатывали люди, которые не имели энное число лет программистского стажа за плечами и которые бы не лезли сами в кодинг. При чём активно и постоянно.

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

Господь с Вами! Переписать заново то над чем 100 человек в течении года работали? Разоритесь быстро.

Заменить алгоритм на более удачную версию - и не разоришься.

Я знаю человека, который один переписал IBM-овский компилятор Фортрана для серии IBM/360. В результате скомпилированные им программы стали делать за полчаса то, что раньше выполнялось несколько суток.

Западная и восточная школы программирования несколько отличаются. На западе все надеются на мыльный пузырь - постоянное повышение производительности аппаратуры. В результате и получаются монстры типа Windows или Adobe CS, которые занимают на диске десятки гигабайт и требуют не менее 1 гигабайта ОЗУ и 4-ядерного 64-битного процессора.

Почистить мусор они ленятся. А процентов 90-95 оттуда можно было безболезненно выбросить.

 

[Kornelia]

Это в очень крупных проектах с тысячами и десятками тысяч участников.

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


Но, кстати, и Ваш вариант не меняет того, что нужны люди, которые в этом деле (алгоритмике) разбираются.

Заменить алгоритм на более удачную версию - и не разоришься.

Чтобы заменить алгоритм нужно
1) точно понять, что он даёт в результате, на основе прочтения кодинга (зачастую много-многостраничного). Что значительно облегчается в случае стандартизированного кодинга. С чего я и начинала.
2) где-то найти более удачную версию того же алгоритма. На практике, зачастую, её кто-то должен написать именно для твоей конкретной проблемы. В результате нам снова нужен человек, умеющий писать удачные алгоритмы или "перекраивать" старые.

Почистить мусор они ленятся. А процентов 90-95 оттуда можно было безболезненно выбросить.

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

 

[aeg]

Чтобы заменить алгоритм нужно
1) точно понять, что он даёт в результате, на основе прочтения кодинга (зачастую много-многостраничного). Что значительно облегчается в случае стандартизированного кодинга. С чего я и начинала.

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

 

[Kornelia]

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

Понятно... значит с SAP-ом в промышленности Вам сталкиваться не доводилось. Это не в коем случае Вам не в упрёк. И ни в коем случае не попытка оспорить Вашу профессиональную квалификацию - SAP на практике дело специфическое.

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

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

 

[aeg]

Понятно... значит с SAP-ом в промышленности Вам сталкиваться не доводилось.

Да, только с 1С И не в промышленности, а в одном американском банке. Я этот ужас выбросил и поставил Novell Groupwise. Они там даже Microsoft Excel не умели пользоваться.

Странно, что утверждается, будто у SAP почти 50% российского рынка, но везде стоит 1С. Видимо, это всё пиратские версии.

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

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

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

 

[Kornelia]

Странно, что утверждается, будто у SAP почти 50% российского рынка, но везде стоит 1С.

За российский рынок ничего сказать не могу.

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

Так отож. И в результате нужны специалисты, способные во всём этом разобраться.

У нас такое могут себе позволить: на один проект выделяется денег примерно столько, какая операционная прибыль для всего SAP.

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

Тут я Вам на слово поверю.

 

[aeg]

Тут я Вам на слово поверю.

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

 

[Kornelia]

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

 

[Гиви Чрелашвили]

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

Отвратительно ! Терпеть не могу оператор безусловного перехода.
Как будто послал контроль куда-то в ж... зад !
А если запутаешься во вложенных условных блоках и один из операторов
(типа GO TO) не выполнится, что тогда ?
А чего, место вставки нельзя подпрограммой оформить, что ли ?
Она автоматически всегда возвращает контроль после вызывающего оператора. Такое способ, насколько я знаю, работает во всех языках программирования высокого уровня.
Даже в Ассемблере это можно сделать при помощи Макросов.
Так, в принципе, и делают (я могу отвечать лишь за MVS Assembler - Mainframe - машины серии IBM/390, в Союзе была такая сворованная у IBM серия EC, на которой я проработал 15 лет).
Такое используют и в FORTRANе, и в COBOLe, и в PL/I.
Внутренние и внешние подпрограммы (в COBOLe роль внутренней подпрограммы выполняет параграф).
В объектно-ориентированном программировании (скажем, будем говорить о Java, ибо .net (Vb.net и C#) я почти не знаю), тот же принцип (вызов методов), да еще и более гибкий: создание объектов на основе вызовов метода отдельного оформленного класса.
Сколько себя помню, никогда не употреблял оператор GO TO.
Принципиально.
Без него всегда можно обойтись, и при этом код будем выглядить более структурированным.
Вам когда-нибудь приходилось разбирать старые программы на FORTRANe, PL/I или COBOLe, написанные по принципу спаггети-кода ?
Уже через час после начала разбора выть хочется !

 

[aeg]

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

Вызов подпрограммы работает медленнее, чем переход. В этом процессоре для вызова требуется сама команда вызова и ещё сохранение из регистра адреса возврата. А для возврата - команда безусловного перехода по сохранённому адресу. То есть 3 команды вместо 2, да ещё ячейку заводить под адрес возврата.

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

Это всё было вообще написано не на ассемблере, а в кодах. Сейчас я сделал там компилятор Си со встроенным ассемблером, в котором память под программы автоматически распределяется, и бантики стали постепенно удалять.

 

[aeg]

Я один раз аналог Goto применял - это функции setjmp и longjmp. Первая сохраняет всё состояние процессора в буфер, а вторая восстанавливает это состояние. При вызове longjmp происходит нелокальный переход (можно даже между функциями). Это полезно при обработке транзакций: если произошла фатальная ошибка, то можно сразу восстановить исходное состояние программы.

 

[Гиви Чрелашвили]

Вызов подпрограммы работает медленнее, чем переход. В этом процессоре для вызова требуется сама команда вызова и ещё сохранение из регистра адреса возврата. А для возврата - команда безусловного перехода по сохранённому адресу. То есть 3 команды вместо 2, да ещё ячейку заводить под адрес возврата.

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

Это всё было вообще написано не на ассемблере, а в кодах. Сейчас я сделал там компилятор Си со встроенным ассемблером, в котором память под программы автоматически распределяется, и бантики стали постепенно удалять.

Aeg, вы меня удивляете.
Судя по всему, вы профессионал.
Что значит медленнее ?
Насколько медленее ?
Даже в те далекие времена эта разница во времени была, может, в несколько миллисекунд процессорного времени, а в сейчас такая разница и вообще в наносекундах будет мерится.
Три команды вместо двух ?
И что ?
Что лучше, иметь на одну команду больше, но программу более четкую и структурированную или абы как сконструированную ?

 

[aeg]

Aeg, вы меня удивляете.
Судя по всему, вы профессионал.

Это не мои программы Я для этого процессора написал компилятор с Си; не очень-то это просто, поскольку у него всего 32 команды.

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

В 1,5-2 раза дольше. Команда перехода с запоминанием выполняется дольше, чем просто переход, да ещё надо сохранить регистр в память.

Программа работает в реальном времени, там скорость важна, а не структурирование. Если выполняется быстрее, то Вы можете, например, не 32 воздушные цели сопровождать, а 100.

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

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

Сейчас бантики постепенно удаляют, так что ещё быстрее будет выполняться.

Наносекунд не будет - процессор частоту имеет менее 1 МГц, а на современной элементной базе может быть получится 32-50 МГц, не более.

 

[Гиви Чрелашвили]

Ну, в современном IBM/390 разница между операциями в наносекунды вполне может быть. Там быстродействие просто бешенное.
Но то, что у вас не процессор IBM/390, это я вполне могу понять.
(Кстати, после миллисекунд до наносекунд идут еще микросекунды).
Впрочем, вы правы.
Каждый конкретный проект каждой компании преследует свою цель.
В компаниях, в которых я работал в США, цели были другие.
Там, допустим, для создания репорта о страховых счетах не принципиально важно будет ли программа работать 15 минут или 25-30 минут
(тоже, между прочим, миллионы записей из базы данных тягаются).
Но в такого рода программы постоянно могут вноситься изменения, ибо требования к такого репорту часто меняются.
И вот представьте такую ситуацию, что человек, который до этого написал и изменял эту программу, ушел из компании по тем или иным причинам.
На его место назначен новый человек, чтобы сопровождать эту программу.
Обычная ситуация, которая встречается постоянно.
Пришли новые требования, программу надо изменить.
Открывает он эту программу, а там сплошные GO TO.
Разобраться досконально в логике совершенно невозможно.
А программа немалого объема и у нее немало функций, обозначающих правила этого репорта на все случаи жизни в зависимости от исходных данных.
Переписать ее полностью очень трудно, ибо времени с момента ее создания прошло уже немало, и по какому принципу некоторые данные для репорта преобразовывались, не помнят даже старожилы, которые остались. Не помнят бизнес-аналисты. Никто не помнит.
Вот так и мучался, менял практически вслепую. Далеко не всё с первого раза получалось. Со второго тоже.
Слава Богу, потом этот репорт, просто исходя из бизнеса, отменили. Устарел он. Но хоть прошло уже больше 11 лет, я эту гребаную программу до сих пор вспоминаю !

 

[Гиви Чрелашвили]

"Наносекунд не будет - процессор частоту имеет менее 1 МГц, а на современной элементной базе может быть получится 32-50 МГц, не более."

Что это за такой тормозной процессор ?
Сегодня в магазинах выбирал как раз себе лаптоп.
Хорошего уровня - это 2,4 Гигогерца.
Но это не предел.
Есть уже в продаже компы с Intel процессором 3,2 Гигогерца, то есть, это 3200 Мегагерц. И это еще не предел.
А вы говорите про 32 Мегагерца, что в 100 раз медленнее.
Что это за старье там у вас ?
А вы такими процессорами ракеты собираетесь сбивать ?

 

[aeg]

А вы такими процессорами ракеты собираетесь сбивать ?

И всё отлично работает. Это самое лучшее в мире изделие для подобной цели. Американский Пэтриот с гигагерцовыми процессорами тратит на одну цель от 2 до 5 ракет, а тут одной ракетой можно обойтись, а иногда и две цели можно одной сбить. На полигоне испытания всё показывают

Дело не в тактовой частоте, а в отсталости на Западе других технологий. В хороших учебниках по программированию (кстати, американских) предупреждали: "Многие программисты купились на чарующую песню компьютера 'Доверься мне, я всё решу'. И это приводило к краху их планов".

Программист полагается на то, что быстрая аппаратура всё вытянет и прикроет его огрехи. Но так не получается. В форс-мажорной ситуации вся система рушится.

 

[aeg]

Сегодня в магазинах выбирал как раз себе лаптоп.
Хорошего уровня - это 2,4 Гигогерца.

Я два года назад себе купил 10 гигагерцовый компьютер. 4 ядра по 2,4 ГГц. Довольно быстро работает. DivX конвертирует в DVD за столько же времени, сколько длится потом просмотр.

Похоже, что 3,2 ГГц всё же предел. Дальше пойдёт увеличение числа ядер и распараллеливание. Охлаждать всё это почти невозможно. Вентилятор огромный надо на процессор ставить.

Самый лучший в этом смысле процессор - Пентиум 100 МГц. И быстрый, и ничего ему не надо. 208-мегагерцовый ARM 9 у меня в телефоне уже иногда греется, это чувствуется.

А одномегагерцовый процессор не CISC, а RISC. Такие намного быстрее обычного процессора при равной тактовой частоте. У Intel x86 сотни команд, а тут всего 32.