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

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

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

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

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

M>В результате возник SQL
Нашол чему радоватся. Совершенно уродский язык. Еслиб не пытались сделать для доможозяек то можно былобы сделать намного лучше.
M>Помню, что давно читал в книгах (и не одной), что одним из преимуществ SQL является близость к английскому языку, и каждый бухгалтер теперь сможет не прибегая к помощи программиста набрать SQL запрос и получить то, что ему надо
Практика показывает что ничерта они не могут. Всеравно программист нужен.
А чтобы хорошо работало нужен хороший программист.

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

S>>Давайте опять воплотим в жизнь идею, что каждая домохозяйка может программировать,
S>>как уже было в начале 90-х в Америке...
M>В результате возник SQL

и 1с у нас...

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

E>Мне кажется, что миф о том, что программисты всегда имеют недостаточной мощьности средства программирования, уже настолько стар, что не заслуживает доверия.

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

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

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

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

E>>Мне кажется, что миф о том, что программисты всегда имеют недостаточной мощьности средства программирования, уже настолько стар, что не заслуживает доверия.

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

Что-то я не помню, чтобы я подобные вещи утверждал. Не приписывай мне чужих фантазий.

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

Так что, речь лучше вести не о том, что "нет технического прогресса", а о том, что "я не могу использовать то, чем владею". Именно "я не могу", а не "инструмент недостаточной мощный".

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

Д>похоже, у тебя сегодня "день некорректных сравнений"
Д>здесь ты опять забыл об очень существенной разнице — у строителей нет (пока) инструментов, которые могут выполнять работу автоматически, без присмотра человека.

А у программистов есть?
Мне почему-то кажется, что когда make автоматически разруливает зависимости и управляет компиляцией, то это такая же малая автоматизация, как распиливание труб отопления болгаркой или поднятие грузов с помощью лебедки -- без человека ни то, ни другое невозможно. Make не сможет вместо меня придумать makefile.

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

Кстати о прорабах. Именно они и доказывают, "что рыба гниет с головы". Если тебе попадается бригада с мухлевщиком-прорабом, то уже не важно, какая квалификация и отношение к работе у остальных работников. Ты все равно останешься с носом. Зато у нормального прораба разгильдяев в бригаде нет, а те, кто есть, знают, что такое относиться к работе спустя рукава.

Ситуация в точности как в командах разработчиков. Люди важнее инструментов.

E>Я всего лишь хочу сказать, что инструменты постоянно развиваются и становятся мощнее и мощнее, но разговоры об их недостаточной мощности никогда не останавливались. Так что дело не в инструментах, а в людях. Если человека не научить достигать цели с имеющимися средствами, то он никогда ее не будет достигать -- только будет постоянно требовать более совершенных инструментов. И оправдывать свои провалы их отсутствием.

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

kan>Как показала практика, программирование в GUI — только для типичных, массовых вещей, притом так, что один раз написал и
kan>забыл, т.е. фактически не для профессиональных программистов.

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

Есть такой графический язык, как LabVIEW. Идея — колоссальная, реализация, извиняюсь, шлак. Программа рисуется в виде схемы, узлы которой представляют из себя произвольные исполняющие сущности (подпрограммы, математические операции, интерфейсы к устройствам, и т.д.), а потоки данных между узлами представлены в виде проводов. Каждый исполняющий узел, в свою очередь, также является схемой (терминальные узлы — это, естественно, не что иное как вызовы функций dll, либо интринсики). Хочешь передать в подпрограмму структуру данных — свяжи провода в кабель, чтобы не загромождать схему. Язык создан, судя по всему, для электронщиков. Теоретически, на этом самом LabView можно напрограммировать всё что угодно, и под любую платформу (с соответствующим кодогенератором). На деле, даже при разрешении 1600x1200 на экране не хватает места. Естественно, скроллинг и большая глубина вложенности узлов, мягко говоря, не благоприятствуют восприятию "кода" человеком.

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

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

S>>>Давайте опять воплотим в жизнь идею, что каждая домохозяйка может программировать,
S>>>как уже было в начале 90-х в Америке...
M>>В результате возник SQL

_>и 1с у нас...

Ага... есть такая тема.

Здравствуйте, Plutonia Experiment, Вы писали:
PE>В своей области специалисты уже сейчас могут формализовать задачу при наличии нужных средств.
Не встречал. Кроме ОЧЕНЬ редких исключений.

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

PE>Вопрос в том, какой процент людей сможет понять этот новый, графический, язык. Люди не умеют формализовать проблему текстом.
PE>Но кто сказал, что такой же процент будет и для графического способо формализации задачи ?
Люди в среднем очень плохо формализуют задачу в голове. Я же сказал — сам по себе язык почти ничего не стоит. Независимо от того, текстовый он, графический, или музыкальный. Люди предпочитают мыслить очень расплывчатыми категориями. Очень редкий специалист сразу точно скажет, чем отличается Клиент от Контрагента и что у них общего. После того, как он это для себя понял, нарисовать два прямоугольника или написать двадцать строк кода проблемы не представляет. Увы, как правило для этого и нужен программист — человек, способный выделить существенное и отбросить несушественное из этого пыльного чулана знаний специалиста.

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

Д> Текущая нехватка программистов вызывается исключительно недостаточным развитием средств программирования, из-за чего "метод монгольских орд" применяется слишком часто.

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

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

kan>>Как показала практика, программирование в GUI — только для типичных, массовых вещей, притом так, что один раз написал и
kan>>забыл, т.е. фактически не для профессиональных программистов.

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

Инженеры создают огромные комплекты сложных чертежей в Автокаде и вполне довольны.

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

B>Есть такой графический язык, как LabVIEW. Идея — колоссальная, реализация, извиняюсь, шлак. Программа рисуется в виде схемы, узлы которой представляют из себя произвольные исполняющие сущности (подпрограммы, математические операции, интерфейсы к устройствам, и т.д.), а потоки данных между узлами представлены в виде проводов. Каждый исполняющий узел, в свою очередь, также является схемой (терминальные узлы — это, естественно, не что иное как вызовы функций dll, либо интринсики). Хочешь передать в подпрограмму структуру данных — свяжи провода в кабель, чтобы не загромождать схему. Язык создан, судя по всему, для электронщиков. Теоретически, на этом самом LabView можно напрограммировать всё что угодно, и под любую платформу (с соответствующим кодогенератором). На деле, даже при разрешении 1600x1200 на экране не хватает места. Естественно, скроллинг и большая глубина вложенности узлов, мягко говоря, не благоприятствуют восприятию "кода" человеком.

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

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

PE>>В своей области специалисты уже сейчас могут формализовать задачу при наличии нужных средств.
S>Не встречал. Кроме ОЧЕНЬ редких исключений.

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

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

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



B>Есть такой графический язык, как LabVIEW. Идея — колоссальная, реализация, извиняюсь, шлак. Программа рисуется в виде схемы, узлы которой представляют из себя произвольные исполняющие сущности (подпрограммы, математические операции, интерфейсы к устройствам, и т.д.), а потоки данных между узлами представлены в виде проводов. Каждый исполняющий узел, в свою очередь, также является схемой (терминальные узлы — это, естественно, не что иное как вызовы функций dll, либо интринсики). Хочешь передать в подпрограмму структуру данных — свяжи провода в кабель, чтобы не загромождать схему. Язык создан, судя по всему, для электронщиков...


Ага, видел этот LabVIEW, такая шняга. Теже электронщики предпочитают C/C++.

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

E>Что-то я не помню, чтобы я подобные вещи утверждал. Не приписывай мне чужих фантазий.

Если изобретают новые, более мощные средства — значит, мощности старых недостаточно. Потому что если всех устраивают существующие инструменты, то никто и не подумает создавать новые.
Так что одно из двух. Или недостаточность мощности инструментов — это не миф, или никакого технического прогресса в этой области нет. Определяйся уж, что ты хотел сказать.

E>Я всего лишь хочу сказать, что инструменты постоянно развиваются и становятся мощнее и мощнее, но разговоры об их недостаточной мощности никогда не останавливались. Так что дело не в инструментах, а в людях. Если человека не научить достигать цели с имеющимися средствами, то он никогда ее не будет достигать -- только будет постоянно требовать более совершенных инструментов. И оправдывать свои провалы их отсутствием.
E>Так что, речь лучше вести не о том, что "нет технического прогресса", а о том, что "я не могу использовать то, чем владею". Именно "я не могу", а не "инструмент недостаточной мощный".

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

E>А у программистов есть?
E>Мне почему-то кажется, что когда make автоматически разруливает зависимости и управляет компиляцией, то это такая же малая автоматизация, как распиливание труб отопления болгаркой или поднятие грузов с помощью лебедки -- без человека ни то, ни другое невозможно. Make не сможет вместо меня придумать makefile.

И снова — неверная аналогия. Написание мэйкфайла — это не распиливание труб, не поднятие грузов и не укладывание кирпича. Это — составление спецификации, где надо пилить трубы, куда поднимать грузы и как укладывать кирпич.

E>Ситуация в точности как в командах разработчиков. Люди важнее инструментов.

Не надо подменять утверждение "инструменты не важны" на "люди важнее инструментов".

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

PE>Я говорю про специалистов, которые инженеры а не лишь бы кто. Инженер — это предполагает что человек будет решать конкретную проблему, и перед эти ему надо формализовать задачу.

Большинство задач в области программирования — "грязные", т.е. такие, которые для формализации задачи требуют полного или частичного ее решения.

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

E>То, что дальше, выделено жирным:
E>

E>Колыбель. Пеленки. Плач.
E>Слово. Шаг. Простуда. Врач.
E>Беготня. Игрушки. Брат .
E>Двор. Качели. Детский сад.
E>Школа. Двойка. Тройка. Пять.
E>Мяч. Подножка. Гипс. Кровать.
E>Драка. Кровь. Разбитый нос.
E>Двор. Друзья. Тусовка. Форс.
E>Институт. Весна. Кусты.
E>Лето. Сессия. Хвосты.
E>Пиво. Водка. Джин со льдом.
E>Кофе. Сессия. Диплом .
E>Романтизм. Любовь. Звезда.
E>Руки. Губы. Ночь без сна.
E>Свадьба. Теща. Тесть. Капкан.
E>Ссора. Клуб. Друзья. Стакан.
E>Дом. Работа.
E>Дом. Семья.
E>Солнце. Лето.
E>Снег. Зима.
E>Сын. Пеленки. Колыбель.
E>Стресс. Любовница. Постель.
E>Бизнес. Деньги. План. Аврал.
E>Телевизор. Сериал.
E>Дача. Вишни. Кабачки.
E>Седина. Мигрень. Очки.
E>Внук. Пеленки. Колыбель.
E>Стресс. Давление. Постель.
E>Сердце. Почки. Кости. Врач.
E>Речи. Гроб. Прощанье. Плач

E>((c) неизвестен)

Уж не хочешь ли ты сказать, что текущий этап — "Сердце. Почки. Кости. Врач."?

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

E>>Что-то я не помню, чтобы я подобные вещи утверждал. Не приписывай мне чужих фантазий.

Д>Если изобретают новые, более мощные средства — значит, мощности старых недостаточно. Потому что если всех устраивают существующие инструменты, то никто и не подумает создавать новые.
Д>Так что одно из двух. Или недостаточность мощности инструментов — это не миф, или никакого технического прогресса в этой области нет. Определяйся уж, что ты хотел сказать.

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

Автор: Дарней
Дата: 22.09.06

, что:

Текущая нехватка программистов вызывается исключительно недостаточным развитием средств программирования, из-за чего "метод монгольских орд" применяется слишком часто.

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

E>>Так что, речь лучше вести не о том, что "нет технического прогресса", а о том, что "я не могу использовать то, чем владею". Именно "я не могу", а не "инструмент недостаточной мощный".

Д>Как ловко. Ты хотел сказать, что те, кто говорят о недостаточной мощности инструментов — это просто неудачники, которые не могут использовать существующие?

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

E>>Ситуация в точности как в командах разработчиков. Люди важнее инструментов.

Д>Не надо подменять утверждение "инструменты не важны" на "люди важнее инструментов".

А где я подменил?

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

RA>Уж не хочешь ли ты сказать, что текущий этап — "Сердце. Почки. Кости. Врач."?

Это уж у кого как. К тому же это является частью "врачебной тайны"