Инструменты
От: McSeem2 США http://www.antigrain.com
Дата: 20.11.10 03:39
Оценка: 28 (8) +7 -1 :))) :)
Давненько не брал я в руки шашки...

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

Вот вам два инструмента:



Слева — дешевый китайский зажим за 5 баксов, кстати, очень удобный для колки орехов
Автор: McSeem2
Дата: 20.11.10
.

Справа — православный американский универсальный гламурный Leatherman. Я от него тащусь — в кармане два ножика и пила и пассатижи с кусачками и три отвертки. Офигительный тул, и главное — сделан очень качественно, ни малейшего люфта.

Но о чем это я? Простейшая задача — перекусить твердый стальной пруток 2мм диаметром. Ну, типа сетки-рабицы. Так вот — нормальный обычный человек при помощи этого Летсермена этого сделать не сможет — сил не хватит. А вот дешевым китайским зажимом — запросто перекусывается! Сам проверял. Правда, зажима хватает на 4-5 перекусов, после чего он плющится, ибо дешевый и сделан из мягкого сплава. Но это не важно.

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

Поэтому и в программизме так же — нет и не может быть универсального средства. Для бизнес-логики наилучшим было бы что-то типа C#, может быть, Nemerle как офигитиельно классная идея. Но извините, для научных расчетов все равно рулит Фортран! Ни C++, ни C#, ни Java — там просто рядом не стояли (а, да, есть Питон в качестве скриптового языка, но это не важно). Для гейм-рендеринга — C++ и ничего другого.

Так что давайте не будем мечтать об абсолютно универсальном языке — он невозможен так же как невозможен универсальный растворитель. Я это к чему — тут какая-то локальная войнушка по поводу Немерле. Я абсолютно против банеров типа "не нужен" — это тупо и оскорбительно. Оскорбительно прежде всего для владельца этого постера — сразу видно, что человек неадекватен. С другой стороны, немерлисты смами напоролись — ибо очень уж агрессивно стали орать.

Чем дольше я живу, тем сильнее убеждаюсь — нету в природе такой профессии как Программист, нету. Есть профессия Инженер. С удовольствием послушаю возражения, что типа "настоящий программист — это ученый" или "настоящий программист — это творческая личность". Нет, люди. Если ты программист — ты инженер и никак иначе.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re: Инструменты
От: Курилка Россия http://kirya.narod.ru/
Дата: 20.11.10 08:56
Оценка: 1 (1) +3
Здравствуйте, McSeem2, Вы писали:

MS>Чем дольше я живу, тем сильнее убеждаюсь — нету в природе такой профессии как Программист, нету. Есть профессия Инженер. С удовольствием послушаю возражения, что типа "настоящий программист — это ученый" или "настоящий программист — это творческая личность". Нет, люди. Если ты программист — ты инженер и никак иначе.


Т.е. у вас строго можно быть одним из трёх: или инжренером, или учёным или творческой личностью?
И имхо инженер — не профессия ибо, более общее понятие.
Re: Инструменты
От: Pavel Dvorkin Россия  
Дата: 20.11.10 09:10
Оценка: +4
Здравствуйте, McSeem2, Вы писали:

MS>Чем дольше я живу, тем сильнее убеждаюсь — нету в природе такой профессии как Программист, нету. Есть профессия Инженер. С удовольствием послушаю возражения, что типа "настоящий программист — это ученый" или "настоящий программист — это творческая личность". Нет, люди. Если ты программист — ты инженер и никак иначе.


Хотел было плюс поставить, но вот за это не поставлю.
With best regards
Pavel Dvorkin
Re: Инструменты
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 20.11.10 09:46
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Поэтому и в программизме так же — нет и не может быть универсального средства. Для бизнес-логики наилучшим было бы что-то типа C#, может быть, Nemerle как офигитиельно классная идея. Но извините, для научных расчетов все равно рулит Фортран! Ни C++, ни C#, ни Java — там просто рядом не стояли (а, да, есть Питон в качестве скриптового языка, но это не важно). Для гейм-рендеринга — C++ и ничего другого.


1. А что на счёт UML?
2. Бизнес-логику обычно рисуют не с помощью языка программирования.

MS>Так что давайте не будем мечтать об абсолютно универсальном языке — он невозможен так же как невозможен универсальный растворитель.


Если этого нет, то это не значит, что это невозможно создать.

MS>Чем дольше я живу, тем сильнее убеждаюсь — нету в природе такой профессии как Программист, нету. Есть профессия Инженер. С удовольствием послушаю возражения, что типа "настоящий программист — это ученый" или "настоящий программист — это творческая личность". Нет, люди. Если ты программист — ты инженер и никак иначе.


В одной многолетней конторе я числился как "инженер-программист".
Вселенная бесконечна как вширь, так и вглубь.
Re[2]: Инструменты
От: Spiceman  
Дата: 20.11.10 11:31
Оценка:
Здравствуйте, Real 3L0, Вы писали:

R3>1. А что на счёт UML?

И много программ ты на нем написал?
R3>2. Бизнес-логику обычно рисуют не с помощью языка программирования.
Что значит нарисовать бизнес-логику? Речь шла не о рисовании диаграмм, а о языке реализации.

MS>>Так что давайте не будем мечтать об абсолютно универсальном языке — он невозможен так же как невозможен универсальный растворитель.

R3>Если этого нет, то это не значит, что это невозможно создать.
Как на счет создать растворитель, который растворяет все, в том числе и любой растворитель?

R3>В одной многолетней конторе я числился как "инженер-программист".

Видимо имелось ввиду, что в первую очередь ты инженер, а во вторую — программист. И как инженер ты должен уметь грамотно пользоваться инструментами и выбирать каждый под свою задачу, а не решать все задачи универсальным инструментом.
Re[3]: Инструменты
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 20.11.10 14:23
Оценка: :)
Здравствуйте, Spiceman, Вы писали:

R3>>1. А что на счёт UML?

S>И много программ ты на нем написал?

UML можно преобразовать в код.

R3>>2. Бизнес-логику обычно рисуют не с помощью языка программирования.

S>Что значит нарисовать бизнес-логику? Речь шла не о рисовании диаграмм, а о языке реализации.

То и значит. Это было небольшое замечание.

S>Как на счет создать растворитель, который растворяет все, в том числе и любой растворитель?


И почему его нельзя создать?

R3>>В одной многолетней конторе я числился как "инженер-программист".

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

Я не знаю, что имелось в виду и кем я был в первую очередь, но в моих должностных обяззанностях фраз об тех или иных инстументах не было.
Вселенная бесконечна как вширь, так и вглубь.
Re: Инструменты
От: IT Россия linq2db.com
Дата: 20.11.10 17:31
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Так что давайте не будем мечтать об абсолютно универсальном языке — он невозможен так же как невозможен универсальный растворитель.


Универсальный инструмент никому не нужен. Нужен инструмент, который будет позволять легко создавать свои собственные инструменты под свои собственные нужды. И ограничен такой инструмент может быть лишь фантазией разработчиков, временем и ограничениями базовой платформы. В случае с Немерле к этому всё и идёт.

MS>Я это к чему — тут какая-то локальная войнушка по поводу Немерле. Я абсолютно против банеров типа "не нужен" — это тупо и оскорбительно. Оскорбительно прежде всего для владельца этого постера — сразу видно, что человек неадекватен.


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

MS>С другой стороны, немерлисты смами напоролись — ибо очень уж агрессивно стали орать.


+100. Выдержки кое-кому точно не хватает.

MS>Чем дольше я живу, тем сильнее убеждаюсь — нету в природе такой профессии как Программист, нету. Есть профессия Инженер. С удовольствием послушаю возражения, что типа "настоящий программист — это ученый" или "настоящий программист — это творческая личность". Нет, люди. Если ты программист — ты инженер и никак иначе.


И что в этом плохого?
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Инструменты
От: Spiceman  
Дата: 21.11.10 08:06
Оценка:
Здравствуйте, Real 3L0, Вы писали:

S>>И много программ ты на нем написал?

R3>UML можно преобразовать в код.
Это не ответ на мой вопрос.

S>>Как на счет создать растворитель, который растворяет все, в том числе и любой растворитель?

R3>И почему его нельзя создать?
Хм. А как он будет существовать, если он растворяет сам себя?

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

Этого и не должно быть в должностных обязанностях. Хотя обычно людей на работу берут на конкретный яп и на конкретные инструменты. Лучше скажи с чем ты не согласен, что инженер должен уметь правильно выбрать инструмент, а не использовать везде универсальный? Или согласен? Мне что-то не понятно.
Re[2]: Инструменты
От: Spiceman  
Дата: 21.11.10 08:58
Оценка:
Здравствуйте, IT, Вы писали:

IT>Универсальный инструмент никому не нужен. Нужен инструмент, который будет позволять легко создавать свои собственные инструменты под свои собственные нужды.

Мне кажется тут ключевое слово "легко". Возможно ли это?
Re[5]: Инструменты
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 21.11.10 11:16
Оценка:
Здравствуйте, Spiceman, Вы писали:

S>>>И много программ ты на нем написал?

R3>>UML можно преобразовать в код.
S>Это не ответ на мой вопрос.

Т.е. если по словам других, UML можно преобразовать в код, но лично я ни разу этого не делал, то это значит, что UML нельзя преобразовать в код? Шикарненько!

S>>>Как на счет создать растворитель, который растворяет все, в том числе и любой растворитель?

R3>>И почему его нельзя создать?
S>Хм. А как он будет существовать, если он растворяет сам себя?

А как, на пример, существует спирт, который испаряется при открытии бутылки?

S>Этого и не должно быть в должностных обязанностях. Хотя обычно людей на работу берут на конкретный яп и на конкретные инструменты. Лучше скажи с чем ты не согласен, что инженер должен уметь правильно выбрать инструмент, а не использовать везде универсальный? Или согласен? Мне что-то не понятно.


Я не согласен с тем, что универсальный инструмент — это плохо/не возможно/не ...
Вселенная бесконечна как вширь, так и вглубь.
Re: Инструменты
От: MasterZiv СССР  
Дата: 21.11.10 11:18
Оценка:
On 20.11.2010 6:39, McSeem2 wrote:

> Давайте поговорим об инструментах. Я очень надедеюсь, что большинство мужкого


+1 по всем пунктам.
Posted via RSDN NNTP Server 2.1 beta
Re: Инструменты
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 21.11.10 11:20
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Поэтому и в программизме так же — нет и не может быть универсального средства. Для бизнес-логики наилучшим было бы что-то типа C#, может быть, Nemerle как офигитиельно классная идея. Но извините, для научных расчетов все равно рулит Фортран! Ни C++, ни C#, ни Java — там просто рядом не стояли (а, да, есть Питон в качестве скриптового языка, но это не важно). Для гейм-рендеринга — C++ и ничего другого.


Кстати, а если создадут язык, который будет тупым объединением всех возможностей всех языков? Например, тот же C++: для верхего уровня, например, MFC; для математики — какая-нибудь библиотека; для гейм — он уже готов. В любой момент можно вызвать любую функцию из любого уровня.
Вселенная бесконечна как вширь, так и вглубь.
Re[2]: Инструменты
От: Pavel Dvorkin Россия  
Дата: 21.11.10 11:46
Оценка:
Здравствуйте, Real 3L0, Вы писали:

R3>Кстати, а если создадут язык, который будет тупым объединением всех возможностей всех языков? Например, тот же C++: для верхего уровня, например, MFC; для математики — какая-нибудь библиотека; для гейм — он уже готов. В любой момент можно вызвать любую функцию из любого уровня.


Пытались в свое время. PL/1 — гибрид Фортрана, Алгола и Кобола. Особой популярностью не пользовался. Его предшественники (кроме Алгола) до сих пор живы, о нем почти не слыхать.
With best regards
Pavel Dvorkin
Re[3]: Инструменты
От: SchweinDeBurg Россия http://zarezky.spb.ru/
Дата: 21.11.10 12:23
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Пытались в свое время. PL/1 — гибрид Фортрана, Алгола и Кобола.


О да, это было нечто, я с него в школе начинал. Плюсы про сравнению с PL/1 — это просто детский лепет.

PD>Его предшественники (кроме Алгола) до сих пор живы, о нем почти не слыхать.


Ну, учитывая тот факт, что правопреемником Алгола стал Паскаль — можно считать, что он тоже вполне живой.
[ posted via RSDN@Home 1.1.4 stable SR1 r568, accompanied by silence ]
- Искренне ваш, Поросенок Пафнутий ~ ICQ#116846877
In Windows, there’s always a catch… © Paul DiLascia
Re[6]: Инструменты
От: Spiceman  
Дата: 21.11.10 13:48
Оценка:
Здравствуйте, Real 3L0, Вы писали:

R3>Т.е. если по словам других, UML можно преобразовать в код, но лично я ни разу этого не делал, то это значит, что UML нельзя преобразовать в код?

Я не отрицал, что UML нельзя преобразовать в код. Сам так делал в простейшем случае. Хотелось бы знать, кто-нибудь реально спроектировал систему полностью в UML и потом собрал код из него полностью или даже сразу исполняемый модуль?

S>>Хм. А как он будет существовать, если он растворяет сам себя?

R3>А как, на пример, существует спирт, который испаряется при открытии бутылки?
Это не то. Имеется ввиду, например, вывести пятно тем же веществом, из которого сделано пятно.

R3>Я не согласен с тем, что универсальный инструмент — это плохо/не возможно/не ...

ТС да пример когда универсальным инструментом нельзя было перекусить толстую проволоку. Если дополнить этот инструмент, чтобы он умел перекусывать толстые проволоки, то он окажется менее уден, его вряд ли положишь в карман.
В Структуре реальности Дойча есть пример — универсальная лаборатория, в которой можно воспроизвести любой процесс из нашей вселенной. Проблема этой лаборатории в том, что она не будет отличаться от самой вселенной.
Re[7]: Инструменты
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 21.11.10 14:38
Оценка:
Здравствуйте, Spiceman, Вы писали:

S>Я не отрицал, что UML нельзя преобразовать в код. Сам так делал в простейшем случае. Хотелось бы знать, кто-нибудь реально спроектировал систему полностью в UML и потом собрал код из него полностью или даже сразу исполняемый модуль?


Не знаю. А разве это невозможно?

S>>>Хм. А как он будет существовать, если он растворяет сам себя?

R3>>А как, на пример, существует спирт, который испаряется при открытии бутылки?
S>Это не то. Имеется ввиду, например, вывести пятно тем же веществом, из которого сделано пятно.

Ну, если это универсальный растворитель, то он не должен оставлять пятен.

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

S>В Структуре реальности Дойча есть пример — универсальная лаборатория, в которой можно воспроизвести любой процесс из нашей вселенной. Проблема этой лаборатории в том, что она не будет отличаться от самой вселенной.

Достижение цели и способ достижения цели — это разные вещи. Мы о чём говорим?
В интернете, кстати, уже есть аналогичные примеры: рекомендательные сервисы, которые исходя из твоего выбора и выбора остальных пользователей дают тебе рекомендацию. Чем больше пользователей будет участвовать в таком сервисе, тем точнее он будет выдавать рекомендации. Т.е. максимальное качество будет достигнуто, когда все пользователи будут участвовать в этом сервисе. Т.е. — вся вселенная.
Вселенная бесконечна как вширь, так и вглубь.
Re[8]: Инструменты
От: hardcase Пират http://nemerle.org
Дата: 21.11.10 16:41
Оценка:
Здравствуйте, Real 3L0, Вы писали:

R3>Чем больше пользователей будет участвовать в таком сервисе, тем точнее он будет выдавать рекомендации.


А как же закон больших чисел?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[3]: Инструменты
От: IT Россия linq2db.com
Дата: 21.11.10 16:58
Оценка:
Здравствуйте, Spiceman, Вы писали:

IT>>Универсальный инструмент никому не нужен. Нужен инструмент, который будет позволять легко создавать свои собственные инструменты под свои собственные нужды.

S>Мне кажется тут ключевое слово "легко". Возможно ли это?

Мне кажется тут ключевое слово "можно". А "лекго" это скорее эмоциональная окраска. Определённые усилия, конечно потребуются, но, например, для создания первой версии компилятора C# на Немерле человеку, никогда ранее не занимавшемуся парсерами, потребовалось около двух недель. Мне кажется, что это в достаточно большой степени "легко".
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Инструменты
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 21.11.10 17:34
Оценка:
Здравствуйте, hardcase, Вы писали:

R3>>Чем больше пользователей будет участвовать в таком сервисе, тем точнее он будет выдавать рекомендации.

H>А как же закон больших чисел?

Никак. Это другой случай.
Вселенная бесконечна как вширь, так и вглубь.
Re: Инструменты
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 21.11.10 18:54
Оценка: 4 (2) +2
Здравствуйте, McSeem2, Вы писали:

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

MS>А важно то, собственно, к чему это я? А важно то, что не бывает универсальных инструментов.

Рискуя быть заминусованным, все же замечу, что такие инструменты есть. Точнее даже, мета-инструменты. Это руки, растущие из плеч в первом случае и голова, находящаяся примерно там же, во втором. А если оно все растет из задницы, то ни универсальные инструменты, ни специализированные особого положительного влияния на процесс не окажут.

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

MS>так же, как универсальный растворитель — его просто не в чем было бы хранить!


В вакууме, удерживая на лету магнитным полем, не?

MS>Я это к чему — тут какая-то локальная войнушка по поводу Немерле.


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

MS>"настоящий программист — это творческая личность"


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

Понятия "творческая профессия" не существует в принципе, как не существовало той ложки перед Нео. Есть понятия "профессиональное творчество" и "творчество в профессии", но они применимы в равной степени и к любому другому нетрививальному роду деятельности, который допускает самовыражение его участников через созидание чего-либо в рамках своих процессов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[8]: Инструменты
От: Spiceman  
Дата: 21.11.10 19:13
Оценка:
Здравствуйте, Real 3L0, Вы писали:

S>>Хотелось бы знать, кто-нибудь реально спроектировал систему полностью в UML и потом собрал код из него полностью или даже сразу исполняемый модуль?

R3>Не знаю. А разве это невозможно?
Зависит от реализации. Должно быть возможно. Но это нафиг никому не нужно.

R3>Ну, если это универсальный растворитель, то он не должен оставлять пятен.

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

R3>Достижение цели и способ достижения цели — это разные вещи. Мы о чём говорим?

О способе достижения — инструментах.

R3>Т.е. максимальное качество будет достигнуто, когда все пользователи будут участвовать в этом сервисе. Т.е. — вся вселенная.

Даже в этом случае я смогу придумать запрос, на который мне не будет дана рекомендация. Или время которое на это потребуется будет очень велико.
Re[4]: Инструменты
От: Spiceman  
Дата: 21.11.10 19:24
Оценка:
Здравствуйте, IT, Вы писали:

IT>Мне кажется тут ключевое слово "можно". А "лекго" это скорее эмоциональная окраска. Определённые усилия, конечно потребуются, но, например, для создания первой версии компилятора C# на Немерле человеку, никогда ранее не занимавшемуся парсерами, потребовалось около двух недель. Мне кажется, что это в достаточно большой степени "легко".


Ты слово "легко" не на то место поставил. Надо не "легко создать универсальный инструмент", а "инструмент, который позволяет легко создавать свои собственные инструменты".
Человек за две недели решил одну задачу с помощью некоторого универсального инструмента — создал компилятор, по сути новый универсальный инструмен. Можно ли с помощью немерле создавать лекго собственные инструменты под конкретные цели? Наверняка найдется цель, под которую это будет легче сделать с помощью друго инструмена (другого языка).
Re[2]: Инструменты
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 21.11.10 19:59
Оценка: :))
Здравствуйте, kochetkov.vladimir, Вы писали:

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


http://40-gorodskaya-poliklinika.spb24.net/
Вселенная бесконечна как вширь, так и вглубь.
Re[9]: Инструменты
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 21.11.10 21:38
Оценка:
Здравствуйте, Spiceman, Вы писали:

S>... Но это нафиг никому не нужно.


Т.е. мы выяснили, что универсальный язык есть, но он нафик никому не нужен.

R3>>Ну, если это универсальный растворитель, то он не должен оставлять пятен.

S>В общем-то да. Он растворит так же и материал, на котором сделано пятно. А нам этого не надо. То есть, нам не нужен универсальный растворитель. Или нужен такой универсальный, который растворяет все что пачкает и не растворяет все что пачкается

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

R3>>Достижение цели и способ достижения цели — это разные вещи. Мы о чём говорим?

S>О способе достижения — инструментах.

Ну так не всё ли равно, какой инструмент, если цель будет достигнута?

R3>>Т.е. максимальное качество будет достигнуто, когда все пользователи будут участвовать в этом сервисе. Т.е. — вся вселенная.

S>Даже в этом случае я смогу придумать запрос, на который мне не будет дана рекомендация. Или время которое на это потребуется будет очень велико.

Нет, рекомендация дана будет, просто её качество будет хуже.
Но основная мысль этого абзаца — большой инструмент есть и им пользуются.
Вселенная бесконечна как вширь, так и вглубь.
Re[5]: Инструменты
От: IT Россия linq2db.com
Дата: 21.11.10 22:53
Оценка:
Здравствуйте, Spiceman, Вы писали:

IT>>Мне кажется тут ключевое слово "можно". А "лекго" это скорее эмоциональная окраска. Определённые усилия, конечно потребуются, но, например, для создания первой версии компилятора C# на Немерле человеку, никогда ранее не занимавшемуся парсерами, потребовалось около двух недель. Мне кажется, что это в достаточно большой степени "легко".


S>Ты слово "легко" не на то место поставил. Надо не "легко создать универсальный инструмент", а "инструмент, который позволяет легко создавать свои собственные инструменты".


Вообще-то я именно это и сказал. Цитирую себя любимого:

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


S>Человек за две недели решил одну задачу с помощью некоторого универсального инструмента — создал компилятор, по сути новый универсальный инструмен. Можно ли с помощью немерле создавать лекго собственные инструменты под конкретные цели? Наверняка найдется цель, под которую это будет легче сделать с помощью друго инструмена (другого языка).


Я в этом нисколечки не сомневаюсь. Но реальность на сегодняшний день такова, что задач, требующих специальных инструментов мильён, а вот этих инструментов или станков, с помощью которых такие инструменты можно создавать самому явно не хватает. Немерле как раз претендует на роль такого станка.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Инструменты
От: IT Россия linq2db.com
Дата: 22.11.10 02:24
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

R3>>Кстати, а если создадут язык, который будет тупым объединением всех возможностей всех языков? Например, тот же C++: для верхего уровня, например, MFC; для математики — какая-нибудь библиотека; для гейм — он уже готов. В любой момент можно вызвать любую функцию из любого уровня.


PD>Пытались в свое время. PL/1 — гибрид Фортрана, Алгола и Кобола. Особой популярностью не пользовался. Его предшественники (кроме Алгола) до сих пор живы, о нем почти не слыхать.


Потому что получился монстр.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Инструменты
От: Pavel Dvorkin Россия  
Дата: 22.11.10 05:54
Оценка: -1
Здравствуйте, IT, Вы писали:


PD>>Пытались в свое время. PL/1 — гибрид Фортрана, Алгола и Кобола. Особой популярностью не пользовался. Его предшественники (кроме Алгола) до сих пор живы, о нем почти не слыхать.


IT>Потому что получился монстр.


И ничего другого не могло получиться.
With best regards
Pavel Dvorkin
Re: Инструменты
От: Eye of Hell Россия eyeofhell.habr.ru
Дата: 22.11.10 08:00
Оценка: +2 :)

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


Мужик, ты гонишь. Нет такой профессии как Инженер, нету. Есть профессия Рабочий. Он работает на работе и делает работу. За деньги. (c) Не-помню-кто.
Re[10]: Инструменты
От: Spiceman  
Дата: 22.11.10 08:23
Оценка:
Здравствуйте, Real 3L0, Вы писали:

R3>Т.е. мы выяснили, что универсальный язык есть, но он нафик никому не нужен.

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

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

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

R3>Ну так не всё ли равно, какой инструмент, если цель будет достигнута?

Как раз таки нет. Можно и пилкой для ногтей арматуру пилить.

R3>Но основная мысль этого абзаца — большой инструмент есть и им пользуются.

Но кроме него пользуются еще и специализированными инструментами.
Я же не против универсальных инструментов, я утверждал, что инженер должен уметь выбирать инструмент под конкретную цель, а не использовать универсальный во всех случаях жизни.
Re[6]: Инструменты
От: Spiceman  
Дата: 22.11.10 08:29
Оценка:
Здравствуйте, IT, Вы писали:

IT>

IT>Универсальный инструмент никому не нужен. Нужен инструмент, который будет позволять легко создавать свои собственные инструменты под свои собственные нужды

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

IT>Немерле как раз претендует на роль такого станка.

Время покажет. Я только за.
Re[11]: Инструменты
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 22.11.10 09:12
Оценка:
Здравствуйте, Spiceman, Вы писали:

R3>>Т.е. мы выяснили, что универсальный язык есть, но он нафик никому не нужен.

S>Я с этим и не спорил. Как бы много универсльных языков, но лучше выбирать язык под конкретную цель.

Не пойму, почему? Допустим, я отлично знаю UML. И допустим, есть транслятор с UML в любой другой язык. Зачем мне знать другой язык?

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

S>Потому что эти нанороботы должны будут знать, что есть грязь, а что основа. Если допустить, что в мире несчетное число различных веществ, то обучить этих роботов, чтоб они чистили все не представляю себе возможным.

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

R3>>Ну так не всё ли равно, какой инструмент, если цель будет достигнута?

S>Как раз таки нет. Можно и пилкой для ногтей арматуру пилить.

А если эта арматура (которую надо распилить) находится там, куда с другим инструментом (кроме как с пилкой для ноктей) не пролезть?

R3>>Но основная мысль этого абзаца — большой инструмент есть и им пользуются.

S>Но кроме него пользуются еще и специализированными инструментами.

Что касается упомянутых мной рекомендательных сервисов, то по моему опыту, если количество пользователей недостаточное или в сервис залазит разработчик (например, накручивая определённые продукты), то эффективность этого сервиса существенно падает. Например я сразу переставал им пользоваться. Т.е. в данной области есть только один инструмент и он огромен.

S>Я же не против универсальных инструментов, я утверждал, что инженер должен уметь выбирать инструмент под конкретную цель, а не использовать универсальный во всех случаях жизни.


Если универсальный инструмент позволяет достигнуть цели (с качеством, аналогичным качеству, если бы был использован специализированный инструмент), то за счёт того, что научиться пользоваться одним инструментом проще, чем многими, такой специалист (инженер) был бы гораздо более полезен.
Вселенная бесконечна как вширь, так и вглубь.
Re: Инструменты
От: Klapaucius  
Дата: 22.11.10 10:05
Оценка: +1 :))
Здравствуйте, McSeem2, Вы писали:

MS>А важно то, собственно, к чему это я? А важно то, что не бывает универсальных инструментов. Универсальный инструмент противоречил бы законам природы, так же, как универсальный растворитель — его просто не в чем было бы хранить!


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

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

MS>Но извините, для научных расчетов все равно рулит Фортран!


Извинить такое утверждение невозможно. Это непростительно.

MS>Чем дольше я живу, тем сильнее убеждаюсь — нету в природе такой профессии как Программист, нету. Есть профессия Инженер. С удовольствием послушаю возражения, что типа "настоящий программист — это ученый" или "настоящий программист — это творческая личность". Нет, люди. Если ты программист — ты инженер и никак иначе.


Хотел было минус поставить, но вот за это не поставлю.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[5]: Инструменты
От: Klapaucius  
Дата: 22.11.10 10:24
Оценка:
Здравствуйте, Spiceman, Вы писали:

S>Хм. А как он будет существовать, если он растворяет сам себя?


Вообще-то раствор по определению состоит из двух разных веществ. Что вы понимаете под "растворением самого себя"? Автодиссоциацию? Ну тогда растворитель, "растворяющий" сам себя вполне возможен. Вода, например, сама себя "растворяет" в смысле автопротолиза.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[6]: Инструменты
От: Klapaucius  
Дата: 22.11.10 10:25
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>состоит из двух разных веществ.


Это я ошибся, конечно. Правильно "из двух и более"
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re: Инструменты
От: ZevS Россия  
Дата: 22.11.10 11:23
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>А важно то, что не бывает универсальных инструментов. Универсальный инструмент противоречил бы законам природы, так же, как универсальный растворитель — его просто не в чем было бы хранить!


А как же кувалда и зубило?
Re[7]: Инструменты
От: March_rabbit  
Дата: 22.11.10 15:52
Оценка:
Здравствуйте, Spiceman, Вы писали:

S>Здравствуйте, Real 3L0, Вы писали:


R3>>Т.е. если по словам других, UML можно преобразовать в код, но лично я ни разу этого не делал, то это значит, что UML нельзя преобразовать в код?

S>Я не отрицал, что UML нельзя преобразовать в код. Сам так делал в простейшем случае. Хотелось бы знать, кто-нибудь реально спроектировал систему полностью в UML и потом собрал код из него полностью или даже сразу исполняемый модуль?
разработчики АСУП для авиационных бортовых систем утверждают, что у них система позволяет нарисовать алгоритм, по которому их система сгенерит, откомпилит и оттестит С код. К которому впоследствии подключается библиотека интерфейсов ввода/вывода и получается готовое ПО. Я склонен верить, ибо там все ПО — это математика. Но пример показателен. В ограниченной области такое можно.
Re: Инструменты
От: Kernan Ниоткуда https://rsdn.ru/forum/flame.politics/
Дата: 22.11.10 16:12
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Давненько не брал я в руки шашки...


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


MS>Вот вам два инструмента:

MS>


MS>Слева — дешевый китайский зажим за 5 баксов, кстати, очень удобный для колки орехов
Автор: McSeem2
Дата: 20.11.10
.


MS>Справа — православный американский универсальный гламурный Leatherman. Я от него тащусь — в кармане два ножика и пила и пассатижи с кусачками и три отвертки. Офигительный тул, и главное — сделан очень качественно, ни малейшего люфта.

И то и другое китайское Г. и для реальных задач не предназначены.
Sic luceat lux!
Re[2]: Инструменты
От: ZevS Россия  
Дата: 22.11.10 16:18
Оценка:
Здравствуйте, Kernan, Вы писали:

K>И то и другое китайское Г. и для реальных задач не предназначены.


Что такое реальные задачи?
Re: Инструменты
От: любой  
Дата: 22.11.10 17:19
Оценка: 3 (1) +1
Здравствуйте, McSeem2, Вы писали:

MS>Поэтому и в программизме так же — нет и не может быть универсального средства. Для бизнес-логики наилучшим было бы что-то типа C#, может быть, Nemerle как офигитиельно классная идея. Но извините, для научных расчетов все равно рулит Фортран! Ни C++, ни C#, ни Java — там просто рядом не стояли (а, да, есть Питон в качестве скриптового языка, но это не важно). Для гейм-рендеринга — C++ и ничего другого.


А мне кажется, что в том и основная проблема, что много всяких инструментов, а языка, как такового, и нет. Нет единого культурного пространства у программистов. Любой язык возьми (не программирования), на нем люди совершенно разных уровней развития, разных профессий могут общаться. Могут говорить об абстрактных вещах. Та же сортировка. Разве есть разница в том, для геймдева сортировать или для бизнес-логики? Разница в других вещах. Например, какую стратегию использовать для менеджмента памяти. Изобретатели языков программирования почему то уверены, что их любимая стратегия — самая лучшая и намертво зашивают ее в язык. Конечно, при таком подходе область применения языка программирования существенно сужается.
художников никогда не обижал
Re[3]: Инструменты
От: Tilir Россия http://tilir.livejournal.com
Дата: 22.11.10 17:20
Оценка:
Здравствуйте, ZevS, Вы писали:

ZS>Что такое реальные задачи?


Это, разумеется, те, которые требуют кувалды и зубила
Re: Инструменты
От: barn_czn  
Дата: 23.11.10 07:00
Оценка:
MS>А важно то, собственно, к чему это я? А важно то, что не бывает универсальных инструментов. Универсальный инструмент противоречил бы законам природы, так же, как универсальный растворитель — его просто не в чем было бы хранить!

Вы привели пример плохого универсального инструмента и тут же сделали неправильный вывод о бесполезности универсальных вещей.
А вот вам хорошие примеры:

1)комбайн
2)мобильный телефон

Про программирование даже говорить не буду, там куча универсальных технологий.
Re: Инструменты
От: borisman3 Канада http://paskoboris.blogspot.com/
Дата: 23.11.10 16:27
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Чем дольше я живу, тем сильнее убеждаюсь — нету в природе такой профессии как Программист, нету. Есть профессия Инженер. С удовольствием послушаю возражения, что типа "настоящий программист — это ученый" или "настоящий программист — это творческая личность". Нет, люди. Если ты программист — ты инженер и никак иначе.


У меня в дипломе написано что я инженер-программист, так что все верно
Re: Инструменты
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.11.10 16:30
Оценка: 5 (2) +1
Здравствуйте, McSeem2, Вы писали:

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


Абсолютно согласен. Хотя почему-то, что их шильдики, что твое сообщение наводит меня на один и тот же вопрос — Причем тут Nemerle? Видимо есть какая-то тайная секта поклонников Nemerle которая таким образом старается его рекламировать.

ЗЫ

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

Почему языки программирования сравниваются с какими-то там инструментами? Язык программирования — это в первую очередь (ты не поверишь) язык. Так что если уж проводить аналогии, то как раз с языками общего назначения.

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

Первая попытка сделать расширяемый язык программирования это Лисп. Нельзя сказать, что попытка провалилась, но конечно же на сегодня Лисп не обладает реальной популярностью. Я думаю, что лисп не завоевал популярность в следствии того, что за расширяемость приходится платить слишком большую плату. Многие чисто физически не могут принять даже синтаксис Лисп. Что уж там говорить о других его особенностях. Nemerle — это новая попытка сделать расширяемый язык. Успешная или нет покажет время. Но, на мой взгляд, это движение в правильном направлении. Через некоторое время это поймут многие. Для меня вопросом является только насколько большим будет это время.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Инструменты
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 23.11.10 20:33
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Почему языки программирования сравниваются с какими-то там инструментами? Язык программирования — это в первую очередь (ты не поверишь) язык. Так что если уж проводить аналогии, то как раз с языками общего назначения.

VD>Если подумать, то почему на одном Русском или Немецком языке можно одновременно рассуждать как о сложных химических процессах, так и о литературе? Да потому, что языки расширяемые.

Подгоняешь под вывод. В частности, и инструмент и язык (общего назначения) — это аналогии ЯП. Следовательно и выводить из них нечего. В первом случае ты сам на это указываешь, а во втором делаешь ту же ошибку. А уж расширяемость языков общего назначения вообще плохая аналогия для расширяемости языков программирования. Вещи совершенно разные.
Re[2]: Инструменты
От: McSeem2 США http://www.antigrain.com
Дата: 24.11.10 01:57
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Хотел было минус поставить, но вот за это не поставлю.


А зря. Ставь на здоровье.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[2]: Инструменты
От: night beast СССР  
Дата: 24.11.10 04:53
Оценка: +1
Здравствуйте, VladD2, Вы писали:


VD>Абсолютно согласен. Хотя почему-то, что их шильдики, что твое сообщение наводит меня на один и тот же вопрос — Причем тут Nemerle? Видимо есть какая-то тайная секта поклонников Nemerle которая таким образом старается его рекламировать.


VD>ЗЫ


VD>Первая попытка сделать расширяемый язык программирования это Лисп. Нельзя сказать, что попытка провалилась, но конечно же на сегодня Лисп не обладает реальной популярностью. Я думаю, что лисп не завоевал популярность в следствии того, что за расширяемость приходится платить слишком большую плату. Многие чисто физически не могут принять даже синтаксис Лисп. Что уж там говорить о других его особенностях. Nemerle — это новая попытка сделать расширяемый язык. Успешная или нет покажет время. Но, на мой взгляд, это движение в правильном направлении. Через некоторое время это поймут многие. Для меня вопросом является только насколько большим будет это время.


казалось бы, и причем здесь Nemerle
кроме него есть много языков, с расширяемым синтаксисом (forth/tcl/tex).
ты случаем не в секте?
Re[3]: Инструменты
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.11.10 07:51
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>Почему языки программирования сравниваются с какими-то там инструментами? Язык программирования — это в первую очередь (ты не поверишь) язык. Так что если уж проводить аналогии, то как раз с языками общего назначения.

VD>>Если подумать, то почему на одном Русском или Немецком языке можно одновременно рассуждать как о сложных химических процессах, так и о литературе? Да потому, что языки расширяемые.

L>Подгоняешь под вывод.


Отнюдь.

L>В частности, и инструмент и язык (общего назначения) — это аналогии ЯП.


Инструмент? С чего бы это? Как раз инструмент — это средство автоматизации относительно узкого круга задач. Часто одной. А язык — это средство выражения широкого спектра мыслей. Не даром существует само понятие "общего назначения". Вот узкоспециализированынй язык (DSL) с натяжкой можно сравнить с инструментом.

L>Следовательно и выводить из них нечего. В первом случае ты сам на это указываешь, а во втором делаешь ту же ошибку.


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

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


Не вижу разницы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Инструменты
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.11.10 07:56
Оценка:
Здравствуйте, night beast, Вы писали:

NB>казалось бы, и причем здесь Nemerle


Зачем повторять мои слова?

NB>кроме него есть много языков, с расширяемым синтаксисом (forth/tcl/tex).


Много? tex не является языком программирвоания. Это язык разметки. tcl скорее тянет на ДСЛ, т.е. с натяжкой можно назвать инструментом. forth — да, не сомненно. Но назвать фаткически два языка термином "много" — это какой не смешной юмор.

NB>ты случаем не в секте?


Чё?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Инструменты
От: night beast СССР  
Дата: 24.11.10 08:04
Оценка:
Здравствуйте, VladD2, Вы писали:

NB>>кроме него есть много языков, с расширяемым синтаксисом (forth/tcl/tex).


VD>Много? tex не является языком программирвоания. Это язык разметки.


это терминологический спор, в который не хотелось бы углубляться.

VD>tcl скорее тянет на ДСЛ, т.е. с натяжкой можно назвать инструментом. forth — да, не сомненно. Но назвать фаткически два языка термином "много" — это какой не смешной юмор.


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

NB>>ты случаем не в секте?

VD>Чё?

Re[4]: Инструменты
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 24.11.10 08:59
Оценка: +1
Здравствуйте, VladD2, Вы писали:

L>>В частности, и инструмент и язык (общего назначения) — это аналогии ЯП.

VD>Инструмент? С чего бы это? Как раз инструмент — это средство автоматизации относительно узкого круга задач. Часто одной. А язык — это средство выражения широкого спектра мыслей. Не даром существует само понятие "общего назначения". Вот узкоспециализированынй язык (DSL) с натяжкой можно сравнить с инструментом.

Опять подгоняешь. Ты даёшь инструменту, ЯОН и ЯП те определения, в которых слова общие. Гораздо важнее семантика. Вот она у пары ЯП-ЯОП ничуть не больше, чем у пары ЯП-инструмент. Тут уже приводили пример инструментов широкого класса. В свою очередь из языков, на которых люди общаются, ты выбрал только "общего назначения", хотя существуют и "DSL"-и.

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

VD>Не вижу разницы.

Смотришь не так. Кроме самого слова у них и общего то ничего нет. Ну, как иллюстрация: расширяемость языков общего назначения — аналогия для расширяемости языка за счёт внесения в него изменений. Появляется новое слово — аналогия появления кейворда, появляется некое направление — внесение поддержки параллелизма на уровне языка, заимствование из других языков — внесение изменений, которые автор видел в другом языке, в язык. И т.д.
Re[2]: Инструменты
От: Undying Россия  
Дата: 24.11.10 15:23
Оценка: 2 (1) +2
Здравствуйте, VladD2, Вы писали:

VD>Если подумать, то почему на одном Русском или Немецком языке можно одновременно рассуждать как о сложных химических процессах, так и о литературе? Да потому, что языки расширяемые. В любом живом языке есть базовая часть, а есть языки предметных областей. Современные языки программирования (за редким исключением) — это монолиты. В них прикладные расширения или вообще не невозможно сделать, или имеются очень ограниченные возможности сделать это.


Из этой аналогии следует прямо противоположный вывод. Что в русском языке расширяемо? Набор слов. Аналогично в любом программном языке можно расширять словарный запас, вводя свои переменные, методы, классы. А все остальное в естественных языках, т.е. пунктуация, падежи, времена, приставки и т.п., практически неизменно. Макросы же позволяют менять что угодно, а не только словарный запас. Соответственно в природе не существует ни одного естественного языка, который можно было бы менять столь же свободно под свои нужды, как это позволяют программные языки реализующие макросы.
Re: Не, программист - не инженер
От: craft-brother Россия  
Дата: 25.11.10 06:43
Оценка: 60 (3) +1 -4 :))) :)
Здравствуйте, McSeem2, Вы писали:

MS>Чем дольше я живу, тем сильнее убеждаюсь — нету в природе такой профессии как Программист, нету. Есть профессия Инженер. С удовольствием послушаю возражения, что типа "настоящий программист — это ученый" или "настоящий программист — это творческая личность". Нет, люди. Если ты программист — ты инженер и никак иначе.



Инженер – это когда с высшим образованием.

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

Инженер – это когда есть законы естественных наук, математики, физики, химии, которые он применяет для конструирования новых продуктов.

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

Программист – это, скорее, гуманитарий, который выражает свои мысли на одном из языков программирования. Главная проблема в том, что разработка ПО это коллективная работа. Коллективное программирование – это скорее похоже на написания за три месяца поэмы «Евгений Онегин» группой товарищей, которые научились писать по-русски, под руководством системного архитектора, А.С. Пушкина.

ИМХО, здесь зарыты основные проблемы разработки ПО.
Re[2]: Не, программист - не инженер
От: SchweinDeBurg Россия http://zarezky.spb.ru/
Дата: 25.11.10 08:20
Оценка: -1
Здравствуйте, craft-brother, Вы писали:

CB>Программист – это, скорее, гуманитарий, который выражает свои мысли на одном из языков программирования.


+1000
[ posted via RSDN@Home 1.1.4 stable SR1 r568, accompanied by silence ]
- Искренне ваш, Поросенок Пафнутий ~ ICQ#116846877
In Windows, there’s always a catch… © Paul DiLascia
Re[2]: Не, программист - не инженер
От: Spiceman  
Дата: 25.11.10 09:16
Оценка:
Здравствуйте, craft-brother, Вы писали:

CB>Инженер – это когда с высшим образованием.


Формально да.

CB>Знаю массу успешных программистов без вышки. А один, вообще, бывший рок-музыкант. Пришел в тестирование заработать на новую гитару, а сейчас — системный архитектор в российском представительстве зарубежного разработчика ПО.


Успешный программист не обязательно инженер.

CB>Инженер – это когда есть законы естественных наук, математики, физики, химии, которые он применяет для конструирования новых продуктов.

CB>Скажите, где у нас законы Ньютона, уравнения Лагранжа или хотя бы сопромат, которые помогли бы мне спроектировать и доказать правильность архитектуры новой нетривиальной программной системы?

А при чем тут перечисленные науки? Я бы назвал — теория информации, теория игр, теория принятия решений, теория управления, кибернетика и много чего еще.

CB>ИМХО, здесь зарыты основные проблемы разработки ПО.


Не понял, где? В том, что создание ПО коллективная работа? Но строительство дома или создание машины тоже коллективная работа, в которой участвует множество инженеров. А вот написать книгу может и один творческий человек.
Re[4]: Инструменты
От: FR  
Дата: 25.11.10 09:43
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Много? tex не является языком программирвоания. Это язык разметки. tcl скорее тянет на ДСЛ, т.е. с натяжкой можно назвать инструментом. forth — да, не сомненно. Но назвать фаткически два языка термином "много" — это какой не смешной юмор.


Их немного, из относительно живых есть еще http://en.wikipedia.org/wiki/Dylan_(programming_language), XL, EasyExtend и q-lang

Ну и с натяжкой сюда же можно и Smalltalk и Rebol, так как и управляющие конструкции и частью синтаксис вполне задаются программистом.
Ну и OCaml с его Camlp4 вполне перекрывают очень большую часть возможностей языков с развитыми макросами.
Re[3]: Не, программист - не инженер
От: craft-brother Россия  
Дата: 25.11.10 09:55
Оценка:
Здравствуйте, Spiceman, Вы писали:


S>А при чем тут перечисленные науки? Я бы назвал — теория информации, теория игр, теория принятия решений, теория управления, кибернетика и много чего еще.


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

CB>>ИМХО, здесь зарыты основные проблемы разработки ПО.


S>Не понял, где? В том, что создание ПО коллективная работа? Но строительство дома или создание машины тоже коллективная работа, в которой участвует множество инженеров. А вот написать книгу может и один творческий человек.


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

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

Где-то, так...
Re[5]: Инструменты
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 25.11.10 11:37
Оценка:
Здравствуйте, FR, Вы писали:

FR>Их немного


Ruby, возможно.
Re[6]: Инструменты
От: FR  
Дата: 25.11.10 11:42
Оценка: +1
Здравствуйте, lomeo, Вы писали:

L>Ruby, возможно.


Ruby скорее в компанию к смаллталку и реболу.
Re[5]: Инструменты
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.10 15:30
Оценка:
Здравствуйте, FR, Вы писали:

FR>Их немного, из относительно живых есть еще http://en.wikipedia.org/wiki/Dylan_(programming_language), XL, EasyExtend и q-lang


Назвать их "живыми" язык не поворачивается.

FR>Ну и с натяжкой сюда же можно и Smalltalk и Rebol, так как и управляющие конструкции и частью синтаксис вполне задаются программистом.


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

FR>Ну и OCaml с его Camlp4 вполне перекрывают очень большую часть возможностей языков с развитыми макросами.


Ближе, но все же к макросам это не имеет отношение. Возможности не сопоставимы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Инструменты
От: FR  
Дата: 25.11.10 15:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Назвать их "живыми" язык не поворачивается.


Ну если так то только лисп и частично форт живые
Немерле еще толком не родился остальные в коме

FR>>Ну и с натяжкой сюда же можно и Smalltalk и Rebol, так как и управляющие конструкции и частью синтаксис вполне задаются программистом.


VD>Они тут совершенно не причем. Если уж говорить о динамике, то тогда уж стоит вспомнить о Руби и Питоне в которых есть другой (но очень действенный) механизм метапрограммирования.


Ну там все-таки другое, синтаксис не трогается.

FR>>Ну и OCaml с его Camlp4 вполне перекрывают очень большую часть возможностей языков с развитыми макросами.


VD>Ближе, но все же к макросам это не имеет отношение. Возможности не сопоставимы.


Так это и есть разновидность макросов парсер + синтаксический препроцессор.
Возможностей конечно меньше чем у макросов в стиле Лиспа/Немерли но на практике очень большую часть
их использования перекрывают, например вы тут где-то недавно приводили примеры встраивания XML/HTML вот
тоже самое http://www.openmirage.org/blog/introduction-to-htcaml или для SQL http://ocsigen.org/macaque/
Re[7]: Инструменты
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.10 16:19
Оценка:
Здравствуйте, FR, Вы писали:

FR>Ну если так то только лисп и частично форт живые

FR>Немерле еще толком не родился остальные в коме

Так и есть. Но, надеюсь, родится. В конце концов не он, так кто-то должен его дело продолжить.

FR>Ну там все-таки другое, синтаксис не трогается.


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

VD>>Ближе, но все же к макросам это не имеет отношение. Возможности не сопоставимы.


FR>Так это и есть разновидность макросов парсер + синтаксический препроцессор.


Не. Это именно что синтаксический препроцессор. Макры, по крайней мере немерловые — это значительно больше. Я даже не знаю как это объяснить. Это нужно просто попробовать и прочувствовать.

FR>Возможностей конечно меньше чем у макросов в стиле Лиспа/Немерли но на практике очень большую часть

FR>их использования перекрывают, например вы тут где-то недавно приводили примеры встраивания XML/HTML вот
FR>тоже самое http://www.openmirage.org/blog/introduction-to-htcaml или для SQL http://ocsigen.org/macaque/

Макры могут намного больше. Хотя и это конечно тоже. Немерловая макра может взаимодействовать с компилятором. Даже когда задача решается чисто синтаксическим препроцессированием, все равно полноценные макросы позволяют сделать решение более удобным.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Не, программист - не инженер
От: IT Россия linq2db.com
Дата: 25.11.10 22:45
Оценка:
Здравствуйте, SchweinDeBurg, Вы писали:

CB>>Программист – это, скорее, гуманитарий, который выражает свои мысли на одном из языков программирования.

SDB>+1000

-1001
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Не, программист - не инженер
От: Кэр  
Дата: 26.11.10 01:47
Оценка:
CB>>>Программист – это, скорее, гуманитарий, который выражает свои мысли на одном из языков программирования.
SDB>>+1000

IT>-1001 * 2


Re[4]: Не, программист - не инженер
От: Кэр  
Дата: 26.11.10 01:50
Оценка:
Здравствуйте, craft-brother, Вы писали:

S>>А при чем тут перечисленные науки? Я бы назвал — теория информации, теория игр, теория принятия решений, теория управления, кибернетика и много чего еще.


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


А почему именно это и какой вы пытаетесь сделать из этого вывод? И как из этого следует что программисты — это, вдруг, гуманитарии? Вы, кстати, не гуманитарий случаем?
Re[5]: Не, программист - не инженер
От: craft-brother Россия  
Дата: 26.11.10 05:51
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Здравствуйте, craft-brother, Вы писали:


S>>>А при чем тут перечисленные науки? Я бы назвал — теория информации, теория игр, теория принятия решений, теория управления, кибернетика и много чего еще.


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


Кэр>А почему именно это и какой вы пытаетесь сделать из этого вывод?


Вывод простой — нет теории, нет инженерии.

Кэр>И как из этого следует что программисты — это, вдруг, гуманитарии?


Не из этого следует. То что программист — гуманитарий следует из того, что он, как и писатель, пишет свои мысли на ЯП, из того, что в программировании EQ гораздо важнее IQ.

Кэр>Вы, кстати, не гуманитарий случаем?


Нет, мех-мат МГУ. До перехода в коммерческую разработку ПО двадцать лет проработал инженером. Есть с чем сравнивать

И еще. Время вхождения в инженерию, это когда ты заработал авторитет среди коллег и тебя слушают не только из вежливости, а с искренним интересом, составляет, примерно, 10 лет. Вчерашний студент в программировании уже через полгода начинает приносить пользу, а еще через год успешной работы его рыночная стоимость возрастает в 2 раза.
Re[6]: Не, программист - не инженер
От: FR  
Дата: 26.11.10 06:19
Оценка:
Здравствуйте, craft-brother, Вы писали:

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


В программировании выход на серьезный уровень те же 10 лет http://www.williamspublishing.com/21-days.html
Re[5]: Не, программист - не инженер
От: FR  
Дата: 26.11.10 06:21
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>А почему именно это и какой вы пытаетесь сделать из этого вывод? И как из этого следует что программисты — это, вдруг, гуманитарии? Вы, кстати, не гуманитарий случаем?


По моему программисты скорее ближе к математикам и гуманитарием назвать нельзя и на полноценного технаря не тянет
Re[6]: Не, программист - не инженер
От: FR  
Дата: 26.11.10 06:27
Оценка:
Здравствуйте, craft-brother, Вы писали:

CB>Вывод простой — нет теории, нет инженерии.


19 век — век инженеров, но теории тогда во многих отраслях не хватало, практика однако работала.

Кэр>>И как из этого следует что программисты — это, вдруг, гуманитарии?


CB>Не из этого следует. То что программист — гуманитарий следует из того, что он, как и писатель, пишет свои мысли на ЯП, из того, что в программировании EQ гораздо важнее IQ.


С писателем очень большая разница, у него нет абсолютно бесстрастного судью который говорит не верю error XXX line YYY
Писатель не создает самостоятельно работающих моделей, только описывает мир.
Re[6]: Не, программист - не инженер
От: Sinix  
Дата: 26.11.10 06:55
Оценка: 15 (3) +2
Здравствуйте, craft-brother, Вы писали:

CB>Не из этого следует. То что программист — гуманитарий следует из того, что он, как и писатель, пишет свои мысли на ЯП, из того, что в программировании EQ гораздо важнее IQ.


Вообще-то точки над i расставили в 68м. Вы почитайте тезисы — никуда особо от граблей не ушли

Разработка ПО — чистейшая инженерия: и без знаний никуда, и без практического опыта/умения извернуться далеко не уедешь. Всего отличий от обычного конструкторского процесса:
— дикое отношение сложности проекта к выделенным ресурсам. Отсюда — стремление решить максимально дёшево (и максимально неподходящим способом) проблемы от предыдущего решения.
— сравнительно никакой этап производства. Отсюда — типичный цикл разработки:

Фактически, до "нормальной" эксплуатации ПО добирается только став легаси. В результате имеем помесь КБ и технички-аварийки, со всеми вытекающими
Re[6]: Не, программист - не инженер
От: Кэр  
Дата: 26.11.10 07:26
Оценка: 1 (1) +6
Здравствуйте, craft-brother, Вы писали:

S>>>>А при чем тут перечисленные науки? Я бы назвал — теория информации, теория игр, теория принятия решений, теория управления, кибернетика и много чего еще.


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


Кэр>>А почему именно это и какой вы пытаетесь сделать из этого вывод?


CB>Вывод простой — нет теории, нет инженерии.


Теории хватает Просто не так много, как, например, в авиа-строении.

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

Лично мне башню оторвало надолго серии, где показывали что такое на самом деле LINQ, что такое монады и как они тут рулят, как оно оборачивается в Rx, какие есть области применения. Я тут заобщался с Эриком Мейером (мега-дядька!) он утверждает и показывает, что Rx на самом деле решает проблему сложности параллельного программирования — я это хотел тут выложить и обсудить, просто руки еще не дошли.

К чему это я. А да — много еще вещей есть на свете, друг Горацио... Будет вам теория, будет. Индустрия просто молодая.

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

Кэр>>И как из этого следует что программисты — это, вдруг, гуманитарии?


CB>Не из этого следует. То что программист — гуманитарий следует из того, что он, как и писатель, пишет свои мысли на ЯП, из того, что в программировании EQ гораздо важнее IQ.


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

CB>Нет, мех-мат МГУ. До перехода в коммерческую разработку ПО двадцать лет проработал инженером. Есть с чем сравнивать


Хм. А сравнения вы приводите какие-то уж совсем. Неинженерные

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


Ага. Смотрите выше про молодую индустрию.
Re[7]: Не, программист - не инженер
От: FR  
Дата: 26.11.10 07:39
Оценка:
Здравствуйте, Кэр, Вы писали:


Кэр>Теории хватает Просто не так много, как, например, в авиа-строении.


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

Кэр>Но так вы дайте индустрии хотя бы сотню лет, чтобы накопить ключевых знаний.


Другим индустриям хватило десятков лет.

Кэр>Лично мне башню оторвало надолго серии, где показывали что такое на самом деле LINQ, что такое монады и как они тут рулят, как оно оборачивается в Rx, какие есть области применения. Я тут заобщался с Эриком Мейером (мега-дядька!) он утверждает и показывает, что Rx на самом деле решает проблему сложности параллельного программирования — я это хотел тут выложить и обсудить, просто руки еще не дошли.


Это все было в 70-ых — 80ых годах.

Кэр>К чему это я. А да — много еще вещей есть на свете, друг Горацио... Будет вам теория, будет. Индустрия просто молодая.


На фоне других уже старая, атомной промышленности например по годам практически столько же. А микроэлектроника гораздо моложе.

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


Это скорее подход инженера конструктора или специалиста ОКР а не простого инженера.

Кэр>Ага. Смотрите выше про молодую индустрию.


Угу в 68 http://www.rsdn.ru/forum/philosophy/4054207.1.aspx
Автор: Sinix
Дата: 26.11.10
была молодая а не сейчас.
Re[7]: Не, программист - не инженер
От: Sinix  
Дата: 26.11.10 07:44
Оценка: +1
Здравствуйте, Кэр, Вы писали:

Поддержу.

Кэр>Теории хватает Просто не так много, как, например, в авиа-строении.

Увы, не всё так хорошо. Во "взрослых" КБ теория _очень_ тесно соседствует с эмпирикой, особенно для для гидродинамики|гиперзвуковой аэродинамики|нагрузочных испытаний.

Кэр>К чему это я. А да — много еще вещей есть на свете, друг Горацио... Будет вам теория, будет. Индустрия просто молодая.

Будет. Но для _выхлопа_ от теории придётся дождаться, пока её не спрячут за чем-то внешне простым и понятным, как тот же Rx. Мейнстрим, увы

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


Задница в том, что мы тут вместе смешиваем и информатику со всеми светлыми идеями, и практически возникающие проблемы, и программную инженерию, несколько от жизни оторванную. И, поскольку все свободно перескакивают с уровня на уровень, холиварить можно до бесконечности
Re[7]: Не, программист - не инженер
От: craft-brother Россия  
Дата: 26.11.10 07:53
Оценка: +1
Здравствуйте, Кэр, Вы писали:

Кэр>Теории хватает Просто не так много, как, например, в авиа-строении.


Кэр>Но так вы дайте индустрии хотя бы сотню лет, чтобы накопить ключевых знаний.


Кэр>К чему это я. А да — много еще вещей есть на свете, друг Горацио... Будет вам теория, будет. Индустрия просто молодая.


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

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


ИМХО, это цикл работы любого научного работника. Не только инженера.
Re[4]: Не, программист - не инженер
От: SchweinDeBurg Россия http://zarezky.spb.ru/
Дата: 26.11.10 08:14
Оценка:
Здравствуйте, IT, Вы писали:

IT>-1001


Эм-м-м... за линейкой идти, Игорь?
[ posted via RSDN@Home 1.1.4 stable SR1 r568, accompanied by silence ]
- Искренне ваш, Поросенок Пафнутий ~ ICQ#116846877
In Windows, there’s always a catch… © Paul DiLascia
Re[8]: Не, программист - не инженер
От: Sinix  
Дата: 26.11.10 08:34
Оценка:
Здравствуйте, craft-brother, Вы писали:

CB>Просто, ИМХО, программирование — новый вид человеческой деятельности. В разработке ПО психологии и социологии больше, чем математики и кибернетики. И самое существенное продвижение в нашей отрасли, полагаю будет, когда мы поймем как человек строит ментальные модели (100% — психология) и создадим адекватный язык их описания. Тогда мы получим и формализацию знаний,и формальные спецификации ПО, и DSL. Правда, насчет прорыва в области искусственного интеллекта, сильно сомневаюсь


Ну да, это один подход.

Второй — что сложно не программирование, а сами решаемые задачи.
С попеременно модными вариантами:
1. Учимся думать и пытаемся схитрить.
2. Делаем всё максимально примитивно, чтобы не добавлять сложности.

Пока что моден второй, с переходящими хайпами на agile/TDD/NoSQL/Cloud/SaaS. Не, ничего плохого, но когда _массово_ вдалбливается превосходство упрощённых частных решений над общими аля:
— компы — слишком сложно, будущее за мобильными интерфейсами "тыкни пальцем".
— захостить два сервиса рядом — сложно, проще написать виртуалку.
— написать спецификацию — сложно, проще сделать как попросили, если что — виноват заказчик.
— поставить программу — сложно, проще щёлкнуть по ссылке.
— хранить локально документы — сложно, проще отдать их хостеру.
— написать запрос на SQL — сложно, проще — EAV.

и в результате — обратный переход от качества к количеству — раздражает

Только разработка ПО тут не причём — общий тренд, чтоб его
Re[8]: Не, программист - не инженер
От: Klapaucius  
Дата: 26.11.10 09:01
Оценка: 7 (1) +2
Здравствуйте, FR, Вы писали:

FR>Угу в 68 http://www.rsdn.ru/forum/philosophy/4054207.1.aspx
Автор: Sinix
Дата: 26.11.10
была молодая а не сейчас.


Я думаю, что молодость индустрии измеряется не годами. Хороший критерий молодости, как мне кажется, это как раз важность специального образования. Пока гитарист может работать программистом — программирование, как вид инженерной деятельности, еще не созрело. Детство индустрии заканчивается, когда на смену Эдисонам приходят Теслы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[9]: Не, программист - не инженер
От: FR  
Дата: 26.11.10 09:26
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Я думаю, что молодость индустрии измеряется не годами. Хороший критерий молодости, как мне кажется, это как раз важность специального образования. Пока гитарист может работать программистом — программирование, как вид инженерной деятельности, еще не созрело.


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

K>Детство индустрии заканчивается, когда на смену Эдисонам приходят Теслы.


Значит софтостроение ни индустрия.
Re[9]: Не, программист - не инженер
От: Sinix  
Дата: 26.11.10 09:37
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Я думаю, что молодость индустрии измеряется не годами. Хороший критерий молодости, как мне кажется, это как раз важность специального образования. Пока гитарист может работать программистом — программирование, как вид инженерной деятельности, еще не созрело. Детство индустрии заканчивается, когда на смену Эдисонам приходят Теслы.


Как _инженер_ Эдисон куда успешнее Теслы С такой точки зрения — молода вся инженерия.

Увы, проблема не в технологиях, а в людях. Главная претензия — фигня выходит — обусловлена тем, что мы пытаемся детерминированно решать сложные задачи, используя мизерные (сравнительно) ресурсы.

Хотя нет, выходит даже не фигня, а примитивный аналог природных систем — работа на случайных побочных эффектах при высокой устойчивости к единичным сбоям.
Re[10]: Не, программист - не инженер
От: Klapaucius  
Дата: 26.11.10 09:45
Оценка:
Здравствуйте, FR, Вы писали:

K>>Я думаю, что молодость индустрии измеряется не годами. Хороший критерий молодости, как мне кажется, это как раз важность специального образования. Пока гитарист может работать программистом — программирование, как вид инженерной деятельности, еще не созрело.


FR>Хирург требует очень продолжительного и сложного образования, но не занимается инженерной деятельностью.


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

FR>Значит софтостроение ни индустрия.


Значит софтостроение — формирующаяся индустрия. Но это временно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[10]: Не, программист - не инженер
От: Klapaucius  
Дата: 26.11.10 09:55
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Как _инженер_ Эдисон куда успешнее Теслы С такой точки зрения — молода вся инженерия.


Эдисон был успешен в формирующейся индустрии. В индустрии сформировавшейся Эдисон — вообще не инженер.

S>Увы, проблема не в технологиях, а в людях. Главная претензия — фигня выходит — обусловлена тем, что мы пытаемся детерминированно решать сложные задачи, используя мизерные (сравнительно) ресурсы.


Используемые ресурсы зависят не только от сложности решаемой задачи, но и от требований к надежности получаемого в результате изделия. В некоторых случаях ресурсы влкдываются вполне значительные, но большинство ПО — наименее надежный продукт человеческой цивилизации. Но это пройдет по мере того, как ПО будет играть в нашей жизни все более важную роль.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[11]: Не, программист - не инженер
От: Sinix  
Дата: 26.11.10 11:04
Оценка: +1
Здравствуйте, Klapaucius, Вы писали:

S>>Как _инженер_ Эдисон куда успешнее Теслы С такой точки зрения — молода вся инженерия.


K>Эдисон был успешен в формирующейся индустрии. В индустрии сформировавшейся Эдисон — вообще не инженер.

Пример сформировавшейся индустрии плиз. Я оччень сомневаюсь, что в КБ Эдисоны не нужны(с). Для начала:

Я не терпел поражений. Я просто нашёл 10 000 способов, которые не работают.

Или вы про личные качества и кинутого Эдисоном Теслу (который вообще-то тоже душкой не был)?

S>>Увы, проблема не в технологиях, а в людях. Главная претензия — фигня выходит — обусловлена тем, что мы пытаемся детерминированно решать сложные задачи, используя мизерные (сравнительно) ресурсы.


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

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

История учит только тому, что история ничему не учит.
Собсно кризис программной инженерии с того и начался, что стоимость разработки ПО выросла выше всяких разумных пределов: разработка ПО для IBM/360 обошлась не сильно дешевле железа (пруф могу поискать, подозреваю что тут я слегка наврал). И да, закидывание человеческими ресурсами не сильно помогает — в довесок к сложной проблеме мы получаем проблему управления большой оргструктурой и нехилые накладные расходы на взаимодействие.

С таким подходом можно говорить, что мы до сих пор не были на Марсе/к звёздам не слетали только потому, что не особо и хотелось.
Re[11]: Не, программист - не инженер
От: FR  
Дата: 26.11.10 11:42
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Я говорю сейчас о том, как определить зрелость инженерной деятельности, а не о том, является ли программирование инженерной дейтельностью.


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

K>Значит софтостроение — формирующаяся индустрия. Но это временно.


Угу сразу же после индустрии межзвездных полетов и сформируется, может быть
Re[12]: Не, программист - не инженер
От: Klapaucius  
Дата: 26.11.10 12:43
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>Пример сформировавшейся индустрии плиз.


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

S>Я оччень сомневаюсь, что в КБ Эдисоны не нужны(с).


В КБ Эдисоны нужны на организатроских и административных должностях. Инженером в современном КБ Эдисон работать не сможет.

S>Или вы про личные качества


Я же написал — я про отсутствие систематического профессионального образования.

S>История учит только тому, что история ничему не учит.


История учит всякого, кто пожелает у нее чему-то поучиться.

S>Собсно кризис программной инженерии с того и начался, что стоимость разработки ПО выросла выше всяких разумных пределов: разработка ПО для IBM/360 обошлась не сильно дешевле железа (пруф могу поискать, подозреваю что тут я слегка наврал).


Программная инженерия, конечно, вечно в кризисе, но я не считаю, что разработка ПО обязательно должна быть дешевле разработки железа.

S>И да, закидывание человеческими ресурсами не сильно помогает — в довесок к сложной проблеме мы получаем проблему управления большой оргструктурой и нехилые накладные расходы на взаимодействие.


Человеческие ресурсы могут быть дорогостоящими, но малочисленными.

S>С таким подходом можно говорить, что мы до сих пор не были на Марсе/к звёздам не слетали только потому, что не особо и хотелось.


Думаю, что люди не были на Марсе первую очередь как раз поэтому.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[12]: Не, программист - не инженер
От: Klapaucius  
Дата: 26.11.10 12:43
Оценка:
Здравствуйте, FR, Вы писали:

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


Ну а чем деятельность программиста отличается от деятельности микроэлектронщика? И те и другие переводят неформальные требования в формальное описание автомата, решающего поставленную задачу. Единственная разница — тиражирование автоматов, которые разрабатывают программисты тривиально, а значит в программировании есть только R&D а вся деятельность связанная с налаживанием серийного производстав отсутствует в принципе.

FR>Угу сразу же после индустрии межзвездных полетов и сформируется, может быть


Гораздо раньше. потому, что потребность в окончательном оформлении программирования как инженерной деятельности давно назрела и это оформление уже идет полным ходом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[13]: Не, программист - не инженер
От: Курилка Россия http://kirya.narod.ru/
Дата: 26.11.10 12:55
Оценка: +2
Здравствуйте, Klapaucius, Вы писали:

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


FR>>Угу сразу же после индустрии межзвездных полетов и сформируется, может быть


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


Можно про полный ход чуть подробней?
Re[13]: Не, программист - не инженер
От: Sinix  
Дата: 26.11.10 13:26
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Выше они называются. Микроэлектроника, например.

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


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

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

Главное — нет великого и непредсказуемого заказчика с пожеланиями квантовой голографии

K>Программная инженерия, конечно, вечно в кризисе, но я не считаю, что разработка ПО обязательно должна быть дешевле разработки железа.


Так не в этом проблема — проблема в том, что вливай бабки-не вливай, полезного эффекта ноль и меньше.
Если посчитать всё, что САП или Оракл вбухали в свои корпоративные решения — у них уже 1000 лет как должно было быть идеальное ПО.

Сложная проблема потому и сложная, что её нельзя решить с разумным количеством ресурсов. С разработчиков регулярнейше требуют универсальный всемогутор, причём ещё вчера — какая тут может быть речь о "развитой индустрии"?

K>Думаю, что люди не были на Марсе первую очередь как раз поэтому.

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

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

При облучении всего тела, 1 Зв вызывает изменения в крови, 2 — 5 Зв вызывает облысение и белокровие, порядка 3 Зв приводит к смерти в течение 30 дней в 50 % случаев

(с)
И да, останется всего-то добыть движок с нормальным энергомассовым совершенством — чтоб не таскать на орбиту очень недешёвые тонны кислородокеросина.

А так — оно конешно, нам просто не надо.
Re[14]: Не, программист - не инженер
От: Klapaucius  
Дата: 26.11.10 13:53
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Увы, по сложность решаемых задач несопоставимы. Типовой девайс — контроллер + обвязка + прошивка + дрова. С последними двумя пунктами — традиционно всё фигово.

S>Если мы про компьютерную микроэлектронику — то да, сами чипы весьма сложные, но основные подходы великолепно формализуются, а процесс автоматизирован от какого-нить OrCADа на входе — до автоматом протестированного кремния на выходе.

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

S>Так не в этом проблема — проблема в том, что вливай бабки-не вливай, полезного эффекта ноль и меньше.


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

S>Сложная проблема потому и сложная, что её нельзя решить с разумным количеством ресурсов. С разработчиков регулярнейше требуют универсальный всемогутор, причём ещё вчера — какая тут может быть речь о "развитой индустрии"?


Вот как раз по этой причине развитая индустрия и сформируется.

S>Ну да Совсем не потому, что у нас систем, способных с гарантированной надёжностью обеспечить доставку туда-обратно пары тушек и сопутствующих запасов (на пару лет). Задача на порядок сложнее, чем поддержать работоспособность жестянки, болтающейся на ~350км (с аварийной капсулой на случай нежданного щастья).

S>И не потому, что нифига непонятно, как быть с радиацией (до 10 Зв если повезло поймать вспышку).

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

S>А так — оно конешно, нам просто не надо.


Почти все, чем мы сегодня ежедневно пользуемся несколько поколений назад просто не существовало. А появилось оно потому, что было надо и все проблемы были успешно решены. Если же что-то не надо — к решению проблем никто и не приступит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[15]: Не, программист - не инженер
От: FR  
Дата: 26.11.10 14:10
Оценка: 1 (1) +1
Здравствуйте, Klapaucius, Вы писали:

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


Боюсь во втором не раньше чем научимся формализовать всю цивилизацию, так как IT по сути превращается в "нервы" этой цивилизации, как энергетика стала ее кровью.
Re[15]: Не, программист - не инженер
От: Sinix  
Дата: 26.11.10 14:12
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


С такой точки зрения кино, тв, музыка и книги стали созревшей индустрией только после выштамповки боевиков, дома 2, фабрики звёзд и Донцовой Даже если не передёргивать, множество областей, например, дизайн не станет индустрией никогда

Я ещё раз повторюсь. 99% задач — автоматизация бардака с очень большой долей неопределённости. Перевоспитаете человечество — будет вам формализуемые и непротиворечивые бизнес-требования. Кое-что сделать можно, но сейчас, наоборот, маятник прёт в сторону максимального упрощения, чуть раньше
Автор: Sinix
Дата: 26.11.10
об этом уже писал.

S>>Сложная проблема потому и сложная, что её нельзя решить с разумным количеством ресурсов. С разработчиков регулярнейше требуют универсальный всемогутор, причём ещё вчера — какая тут может быть речь о "развитой индустрии"?


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


А теперь вы ставите лошадь позади телеги Ничего и никогда не разрабатывалось целенаправленно. Никто не изобретал именно сотовый телефон, просто существующие технологии применялись, чтобы наиболее эффективно покрыть потребность в общении на расстоянии. Фундаментальные исследования потому и фундаментальные, что нифига не известно, дадут ли они хоть какой-то выхлоп и в какой стороне аукнется.
Re[13]: Не, программист - не инженер
От: IT Россия linq2db.com
Дата: 26.11.10 14:50
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Ну а чем деятельность программиста отличается от деятельности микроэлектронщика?


Тем, что программист гораздо чаще сталкивается с противоречивыми требованиями, чем микроэлектронщик. Например, у микроэлектронщика никогда не бывает 13 месяцев в году, который начинается в октябре.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Не, программист - не инженер
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.11.10 16:07
Оценка:
Здравствуйте, Sinix, Вы писали:

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


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


S>С такой точки зрения кино, тв, музыка и книги стали созревшей индустрией только после выштамповки боевиков, дома 2, фабрики звёзд и Донцовой Даже если не передёргивать, множество областей, например, дизайн не станет индустрией никогда


Уууу.... дизайн уже давно стал индустрией. Особенно так называемый "промышленный дизайн".
Но не все в курсе

С разработкой ПО тоже самое. Только в курсе еще меньше людей.
Да и разработчикам выгоднее быть "шаманами", а не "инженерами".


S>Я ещё раз повторюсь. 99% задач — автоматизация бардака с очень большой долей неопределённости. Перевоспитаете человечество — будет вам формализуемые и непротиворечивые бизнес-требования. Кое-что сделать можно, но сейчас, наоборот, маятник прёт в сторону максимального упрощения, чуть раньше
Автор: Sinix
Дата: 26.11.10
об этом уже писал.


Есть хорошая книга брукса Design of Design. Её стоит прочитать чтобы понимать корень проблем.

S>>>Сложная проблема потому и сложная, что её нельзя решить с разумным количеством ресурсов. С разработчиков регулярнейше требуют универсальный всемогутор, причём ещё вчера — какая тут может быть речь о "развитой индустрии"?


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


S>Ничего и никогда не разрабатывалось целенаправленно.

Ну бред же.

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

Конкретно сотовый телефон никто не изобретал, а вот радиосвязь — вполне. Радиорелейная связь тоже вполне целенаправлено изобреталась. Цифровая передача сигналов тоже. А потом собрав все вместе действительно получили сотовые.
Re[14]: Не, программист - не инженер
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.11.10 16:08
Оценка:
Здравствуйте, IT, Вы писали:

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


K>>Ну а чем деятельность программиста отличается от деятельности микроэлектронщика?


IT>Тем, что программист гораздо чаще сталкивается с противоречивыми требованиями, чем микроэлектронщик.

Уверен? Ты настолько хорошо знаешь микроэлектронику?
Re[15]: Не, программист - не инженер
От: IT Россия linq2db.com
Дата: 26.11.10 16:36
Оценка:
Здравствуйте, gandjustas, Вы писали:

IT>>Тем, что программист гораздо чаще сталкивается с противоречивыми требованиями, чем микроэлектронщик.

G>Уверен? Ты настолько хорошо знаешь микроэлектронику?

Уверен.
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Не, программист - не инженер
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.11.10 19:49
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>Только разработка ПО тут не причём — общий тренд, чтоб его


Напомнило анекдот:

-Дорогой, будь осторожнее, по радио говорят что на МКАДе какой-то псих прет против движения
-Да их тут тысячи!!!

Re[16]: Не, программист - не инженер
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.11.10 19:52
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>>>Тем, что программист гораздо чаще сталкивается с противоречивыми требованиями, чем микроэлектронщик.

G>>Уверен? Ты настолько хорошо знаешь микроэлектронику?

IT>Уверен.


Не сомневался, но больше интересует выделенное.

ЗЫ Вообще есть тенденция недооценки сложности той области, в которой не разбираешься и переоценки той, в которой разбираешься.
Re[17]: Не, программист - не инженер
От: IT Россия linq2db.com
Дата: 26.11.10 20:54
Оценка: 4 (1) +1
Здравствуйте, gandjustas, Вы писали:

IT>>>>Тем, что программист гораздо чаще сталкивается с противоречивыми требованиями, чем микроэлектронщик.

G>>>Уверен? Ты настолько хорошо знаешь микроэлектронику?
IT>>Уверен.
G>Не сомневался, но больше интересует выделенное.

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

G>ЗЫ Вообще есть тенденция недооценки сложности той области, в которой не разбираешься и переоценки той, в которой разбираешься.


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

ЗЫ. Я не говорю что в микроэлектронике с требованиями всё в порядке. Там тоже есть свои козявки. Но такого бардака как в софтострое нет больше нигде. В софтострое тоже, кстати, везде по разному. Например, разработка компонентов имеет более чёткие и более формализуемые требования и в этом смысле она ближе к микроэлектронике. Но разработка энтерпрайзов по определению — это "пойди туда не знаю куда, принеси то не знаю что".
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: Не, программист - не инженер
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 27.11.10 01:38
Оценка:
Здравствуйте, IT, Вы писали:

G>>ЗЫ Вообще есть тенденция недооценки сложности той области, в которой не разбираешься и переоценки той, в которой разбираешься.


IT>Ещё есть тенденция игнорировать здравый смысл. Мне пока не приходилось видеть электронщика, который берёт работающую железяку и переделывает её под текущие нужды бизнеса. А с софтом такие выкрутасы проделываются сплошь и рядом. Фактически сегодня успешность бизнеса определяется умением софта подстраиваться под его нужны.


IT>ЗЫ. Я не говорю что в микроэлектронике с требованиями всё в порядке. Там тоже есть свои козявки. Но такого бардака как в софтострое нет больше нигде. В софтострое тоже, кстати, везде по разному. Например, разработка компонентов имеет более чёткие и более формализуемые требования и в этом смысле она ближе к микроэлектронике. Но разработка энтерпрайзов по определению — это "пойди туда не знаю куда, принеси то не знаю что".


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

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

Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью".
Re[17]: Не, программист - не инженер
От: Sinix  
Дата: 27.11.10 05:19
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Уууу.... дизайн уже давно стал индустрией. Особенно так называемый "промышленный дизайн".

G>Но не все в курсе
Так на это и намекаю

G>Есть хорошая книга брукса Design of Design. Её стоит прочитать чтобы понимать корень проблем.

Ещё в апреле

G>Ну бред же.

G>Конкретно сотовый телефон никто не изобретал, а вот радиосвязь — вполне. Радиорелейная связь тоже вполне целенаправлено изобреталась. Цифровая передача сигналов тоже. А потом собрав все вместе действительно получили сотовые.

Бред, да. Но если оппонент настаивает на формализме до последнего — почему нельзя мне?

А так — смотрите: как минимум 70 лет возились со всякой фигнёй. Затем собрали наночумодан на когерерах ака трубки Бранли, как-то не похожий на современные приёмники:

Когерер был изобретен Эдвардом Бранли в 1890 г. и представлял собой стеклянную трубку, наполненную металлическими опилками, которые могли резко и намного (в несколько сот раз) менять свою проводимость под воздействием радиосигнала. Сигнал вызывал проскакивание множества искр между отдельными опилками. Искры разрушали слой окисла на их поверхности, и они «сплавлялись» друг с другом. Для приведения «трубки Бранли» в первоначальное состояние для детектирования новой волны её нужно было встряхнуть, чтобы нарушить контакт между опилками.

Не, это тоже нифига не индустрия
Re[19]: Не, программист - не инженер
От: FR  
Дата: 27.11.10 08:11
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>Ну то что ты говоришь называется различной ценой ошибки. Если ошибка в требованиях, выявленная после запуска в производство, в минкроэлектронике это 100% провал, то в софтостроении можно исправить, хоть и с большими трудозатратами.


Я хоть и далек от микроэлектроники но слова "microcode update" слышал

G>Инженеры-микроэлектронщики понимают цену такой ошибки и используют методы для максимального снижения риска.

G>Инженеры-программисты зачастую не понимают цену ошибки до того как она произойдет и соответствующих методов не применяют.

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

G>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью".


Очень даже коррелируют.
Re[20]: Не, программист - не инженер
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 27.11.10 08:40
Оценка: :)
Здравствуйте, FR, Вы писали:

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


G>>Ну то что ты говоришь называется различной ценой ошибки. Если ошибка в требованиях, выявленная после запуска в производство, в минкроэлектронике это 100% провал, то в софтостроении можно исправить, хоть и с большими трудозатратами.


FR>Я хоть и далек от микроэлектроники но слова "microcode update" слышал


Тоже метод снижения рисков.

G>>Инженеры-микроэлектронщики понимают цену такой ошибки и используют методы для максимального снижения риска.

G>>Инженеры-программисты зачастую не понимают цену ошибки до того как она произойдет и соответствующих методов не применяют.

FR>Когда нужно программисты тоже понимают цену ошибок и разрабатывают с минимизацией ошибок, вот только строка такого кода стоит

FR>на порядок дороже и строк этих (учитывая тесты и переписывание) приходится писать намного больше.

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

G>>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью".

FR>Очень даже коррелируют.
Ты для начала формализуй понятие "сложности".
Re[21]: Не, программист - не инженер
От: FR  
Дата: 27.11.10 09:36
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>Это какой-то неправильный метод, ибо он по сути повышает риски. Если тебе по какой-то причине приходится писать больше и "дороже", то это никак не страхует тебя от последующего переписывания, даже наоборот. Правильный путь — писать меньше и "дешевле".


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


G>>>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью".

FR>>Очень даже коррелируют.
G>Ты для начала формализуй понятие "сложности".

Тут уже был флейм на много страниц.
Re[22]: Не, программист - не инженер
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 27.11.10 09:51
Оценка:
Здравствуйте, FR, Вы писали:

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


G>>Это какой-то неправильный метод, ибо он по сути повышает риски. Если тебе по какой-то причине приходится писать больше и "дороже", то это никак не страхует тебя от последующего переписывания, даже наоборот. Правильный путь — писать меньше и "дешевле".


FR>Уж какой есть, других работающих пока нет.

FR>Те же военные и ракетчики не ленятся и две и больше независимо разработанных программ для особо критических мест писать и делать
FR>перекрестную проверку. Что не мешает там же применять и формальную верификацию, которая для сколько не будь не тривиальных программ
FR>очень сложна.
У них софт, который скорее "хард". Цена ошибки примерно такая же как у электронщиков, и методы соответствующие.
Кода делаешь программы для бизнеса, условия другие.


G>>>>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью".

FR>>>Очень даже коррелируют.
G>>Ты для начала формализуй понятие "сложности".
FR>Тут уже был флейм на много страниц.
И без окончательного решения
Re[14]: Не, программист - не инженер
От: Klapaucius  
Дата: 27.11.10 10:17
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Можно про полный ход чуть подробней?


Да, говоря про полный ход, я, конечно, здорово преувеличил.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[14]: Не, программист - не инженер
От: Klapaucius  
Дата: 27.11.10 10:17
Оценка:
Здравствуйте, IT, Вы писали:

IT>Тем, что программист гораздо чаще сталкивается с противоречивыми требованиями, чем микроэлектронщик.


Я думаю это потому, что тем, кто выдает требования электронщикам, противоречивые требования просто не по карману. Иначе микроэлектронщики сталкивались с такими же требованиями так же часто. Из этого, по-моему, скорее можно сделать вывод о том, что микроэлектроника — более сложная отрасль. Но не обязательно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[16]: Не, программист - не инженер
От: Klapaucius  
Дата: 27.11.10 10:17
Оценка:
Здравствуйте, FR, Вы писали:

FR>Боюсь во втором не раньше чем научимся формализовать всю цивилизацию, так как IT по сути превращается в "нервы" этой цивилизации, как энергетика стала ее кровью.


А чем цивилизация отличается от ее отсутствия кроме формализованности?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[16]: Не, программист - не инженер
От: Klapaucius  
Дата: 27.11.10 10:17
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Я ещё раз повторюсь. 99% задач — автоматизация бардака с очень большой долей неопределённости.


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

S>Перевоспитаете человечество — будет вам формализуемые и непротиворечивые бизнес-требования.


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

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


А какое отношение пилотируемая экспедиция на Марс имеет к фундаментальным исследованиям? Да даже экспериментальная планетология получит от беспилотных зондов за те же деньги полезный выхлоп на три порядка больше. Польза от экспедиции будет только в отработке технологий, которые до нее были не нужны, ядерных лампочек, каких нибудь. Я о том и говорю, потребность в общении на расстоянии двигала развитие соотвествующих технологий. Потребности в полете на Марс практически нет, а все необходимые для такого полета фундаментальные исследования уже проделаны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[17]: Не, программист - не инженер
От: FR  
Дата: 27.11.10 10:36
Оценка:
Здравствуйте, Klapaucius, Вы писали:


K>А чем цивилизация отличается от ее отсутствия кроме формализованности?


Это далеко не та формализация которая требуется вычислительным устройствам.

Отличается все-таки не степенью формализации (это скорее следствие) а степенью
организованности и способностью устойчиво и долговременно поддерживать эту
организованность.
Re[17]: Не, программист - не инженер
От: Sinix  
Дата: 27.11.10 10:45
Оценка:
Здравствуйте, Klapaucius, Вы писали:

S>>Я ещё раз повторюсь. 99% задач — автоматизация бардака с очень большой долей неопределённости.

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

Вы неисправимы Любая программа, увы, работает не в вакууме, её конечная цель — автоматизация действий заказчика — того самого бардака. Соответственно, требования и пожелания к системе — малопредсказуемы и зачастую необъективны. Да, мы можем отсечь всю дурь и написать сферокод, идеальный в своей законченной бесполезности. Или смириться с тем, что _мы не знаем_ что нужно от системы, и удастся ли это реализовать и делать то, что возможно, и переделывать при очередном "усё пропало".

Я в этой ветке закруглюсь — всё что хотел высказал, по кругу ходить не хоцца. Спасибо!
Re[18]: Не, программист - не инженер
От: Klapaucius  
Дата: 27.11.10 10:50
Оценка:
Здравствуйте, FR, Вы писали:

K>>А чем цивилизация отличается от ее отсутствия кроме формализованности?

FR>Это далеко не та формализация которая требуется вычислительным устройствам.

Если бы она была в точности та — работа программиста была бы ненужной.

FR>Отличается все-таки не степенью формализации (это скорее следствие) а степенью

FR>организованности и способностью устойчиво и долговременно поддерживать эту
FR>организованность.

Да, все верно. И по мере того, как IT будет "превращаться в "нервы" этой цивилизации", придется IT от детских болезней избавляться. Как раз в интересах поддержания организованности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[18]: Не, программист - не инженер
От: Klapaucius  
Дата: 27.11.10 11:03
Оценка: 15 (1) +2
Здравствуйте, Sinix, Вы писали:

S>Вы неисправимы Любая программа, увы, работает не в вакууме, её конечная цель — автоматизация действий заказчика — того самого бардака. Соответственно, требования и пожелания к системе — малопредсказуемы и зачастую необъективны. Да, мы можем отсечь всю дурь и написать сферокод, идеальный в своей законченной бесполезности.


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

S>Или смириться с тем, что _мы не знаем_ что нужно от системы, и удастся ли это реализовать и делать то, что возможно, и переделывать при очередном "усё пропало".


Не нужно ни с чем смиряться. Нужно вооружиться познавательным оптимизмом, гибкой и современной методологией и отвоевывать землю упорядоченности у болота бардака. Потому, что без этого реализовать ничего не удасться. Это главное из того, что помогло человечеству чего-то достичь за последние два — три века после тысячелетий стагнации.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[15]: Не, программист - не инженер
От: IT Россия linq2db.com
Дата: 27.11.10 16:25
Оценка:
Здравствуйте, Klapaucius, Вы писали:

IT>>Тем, что программист гораздо чаще сталкивается с противоречивыми требованиями, чем микроэлектронщик.


K>Я думаю это потому, что тем, кто выдает требования электронщикам, противоречивые требования просто не по карману. Иначе микроэлектронщики сталкивались с такими же требованиями так же часто.


Совершенно верно.

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


Нет. Из этого можно сделать вывод лишь о том, что тем, кто выдает требования электронщикам, противоречивые требования просто не по карману.
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: Не, программист - не инженер
От: IT Россия linq2db.com
Дата: 27.11.10 16:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ну то что ты говоришь называется различной ценой ошибки. Если ошибка в требованиях, выявленная после запуска в производство, в минкроэлектронике это 100% провал, то в софтостроении можно исправить, хоть и с большими трудозатратами.


Не важно как это называется. Важно, что в электронике требования обязаны быть более чётко формализированы.

G>Инженеры-микроэлектронщики понимают цену такой ошибки и используют методы для максимального снижения риска.

G>Инженеры-программисты зачастую не понимают цену ошибки до того как она произойдет и соответствующих методов не применяют.

Всё они понимают. В нашей команде, например, на этом понимании построена архитектура приложений и весь тех. процесс.

G>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью".


Так не бывает. Факторы есть, а корреляции нет Есть вполне объективная сложность — сложность понимания решаемой задачи. В программировании для управления такой сложностью как раз в обсуждаемом контексте используются методологии из серии XP и Agile. Что-то подобное есть у электронщиков?
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: Не, программист - не инженер
От: IT Россия linq2db.com
Дата: 27.11.10 17:16
Оценка: +2
Здравствуйте, Klapaucius, Вы писали:

K>Да, все верно. И по мере того, как IT будет "превращаться в "нервы" этой цивилизации", придется IT от детских болезней избавляться. Как раз в интересах поддержания организованности.


Боюсь, не всё так просто. В сравнении с другими инжинерными дисциплинами у IT есть пара принципиальных отличий:

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

Эти два фактора кардинально расширяют диапозон применения IT решений. Настолько кардинально, что предыдущие опыты "поддержания организованности" и борьбы с детскими болезными работать просто не будут.
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Не, программист - не инженер
От: Sinix  
Дата: 27.11.10 17:44
Оценка:
Здравствуйте, IT, Вы писали:

IT> — очень низкий порог вхождения для получения хоть какого-нибудь результата,

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

В штучном производстве железяк щас к тому же идёт. Самодельщики уже брезгуют лазерным утюгом — подавай готовый набор или принт-сервис.

А "разработка" всякой требухи аля дешёвые плееры/наушники вообще почти вся превратилась в выбор чипа/корпуса из предложенных ОЕМом.

Так что, глядишь, XP придёт и к хардварщикам
Re[20]: Не, программист - не инженер
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 27.11.10 17:54
Оценка:
Здравствуйте, IT, Вы писали:

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


G>>Ну то что ты говоришь называется различной ценой ошибки. Если ошибка в требованиях, выявленная после запуска в производство, в минкроэлектронике это 100% провал, то в софтостроении можно исправить, хоть и с большими трудозатратами.


IT>Не важно как это называется. Важно, что в электронике требования обязаны быть более чётко формализированы.

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

Да и как-то более принято использовать существующие компоненты, а не изобретать новые.

У программистов при этом:
1)Очень модно изобретать велосипеды
2)Очень модно использовать низкоуровневые средства
3)Совсем не модно использовать различные конструкторы и другие средства быстрого создания прототипов
4)Совсем не модно искать количественные характеристики программ и как-то работать с ними

Причем индустрия предлагает все это, но далеко не все хотят пользоваться.

G>>Инженеры-микроэлектронщики понимают цену такой ошибки и используют методы для максимального снижения риска.

G>>Инженеры-программисты зачастую не понимают цену ошибки до того как она произойдет и соответствующих методов не применяют.

IT>Всё они понимают. В нашей команде, например, на этом понимании построена архитектура приложений и весь тех. процесс.


Очень повезло.

G>>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью".

IT>Так не бывает. Факторы есть, а корреляции нет
Бывает.

IT>Есть вполне объективная сложность — сложность понимания решаемой задачи.

Думаешь таковая сложность не присутствует у электронщиков? Или у любых других инженеров?

IT>В программировании для управления такой сложностью как раз в обсуждаемом контексте используются методологии из серии XP и Agile. Что-то подобное есть у электронщиков?

Хм... а что такое XP и Agile, если отбросить написание кода?
1)Частые поставки
2)Приемочные тесты
и собственно все...
Думаешь у электронщиков такого нет?
Только для "частых поставок" используются не готовые изделия, а средства моделирования (чуть более чем все — компьютерные).
Re[21]: Не, программист - не инженер
От: FR  
Дата: 27.11.10 18:42
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Только для "частых поставок" используются не готовые изделия, а средства моделирования (чуть более чем все — компьютерные).


Угу вот только у нас готовые изделия по сути и являются средствами моделирования.
Re[21]: Не, программист - не инженер
От: IT Россия linq2db.com
Дата: 27.11.10 22:57
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>Так что, глядишь, XP придёт и к хардварщикам


Я не сомневаюсь. Только это будет уже разработка схем не с паяльником в руках, а с мышкой.
Если нам не помогут, то мы тоже никого не пощадим.
Re[21]: Не, программист - не инженер
От: IT Россия linq2db.com
Дата: 27.11.10 23:24
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

IT>>Не важно как это называется. Важно, что в электронике требования обязаны быть более чётко формализированы.

G>Кому обязаны?

Здравому смыслу.

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

G>Максимум модели на компьютере гонять будут.

Точно. Да и вообще побольше постараются смоделировать.

G>Да и как-то более принято использовать существующие компоненты, а не изобретать новые.


Принято по тем же самым причинам.

G>У программистов при этом:

G>1)Очень модно изобретать велосипеды

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

G>2)Очень модно использовать низкоуровневые средства


Не знаю где это модно.

G>3)Совсем не модно использовать различные конструкторы и другие средства быстрого создания прототипов


Конструкторы используются постоянно и повсеместно. По-крайней мере System.String никто для себя без особой надобности не пишет. А средства быстрого создания прототипов вообще не понятно что такое.

G>4)Совсем не модно искать количественные характеристики программ и как-то работать с ними


А где это модно?

G>Причем индустрия предлагает все это, но далеко не все хотят пользоваться.


Раз не хотят, значит им не нужно.

IT>>Всё они понимают. В нашей команде, например, на этом понимании построена архитектура приложений и весь тех. процесс.

G>Очень повезло.

Не повезло, а образ мышления.

G>>>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью".

IT>>Так не бывает. Факторы есть, а корреляции нет
G>Бывает.

Не бывает. Законы сохранения, точнее закон равновесия, не обманешь.

IT>>Есть вполне объективная сложность — сложность понимания решаемой задачи.

G>Думаешь таковая сложность не присутствует у электронщиков? Или у любых других инженеров?

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

IT>>В программировании для управления такой сложностью как раз в обсуждаемом контексте используются методологии из серии XP и Agile. Что-то подобное есть у электронщиков?

G>Хм... а что такое XP и Agile, если отбросить написание кода?
G>1)Частые поставки
G>2)Приемочные тесты
G>и собственно все...
G>Думаешь у электронщиков такого нет?
G>Только для "частых поставок" используются не готовые изделия, а средства моделирования (чуть более чем все — компьютерные).

И какой из этого следует вывод?
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Не, программист - не инженер
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 28.11.10 08:12
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>>>Не важно как это называется. Важно, что в электронике требования обязаны быть более чётко формализированы.

G>>Кому обязаны?
IT>Здравому смыслу.
А чем разработка ПО хуже? Там меньше здравого смысла?

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

G>>Максимум модели на компьютере гонять будут.
IT>Точно. Да и вообще побольше постараются смоделировать.

G>>Да и как-то более принято использовать существующие компоненты, а не изобретать новые.

IT>Принято по тем же самым причинам.

G>>У программистов при этом:

G>>1)Очень модно изобретать велосипеды
IT>Потому что велосипеды каждый раз нужны с чуть более другими характеристиками.
Наверное считают что нужны велосипеды с другими характеристиками.

G>>2)Очень модно использовать низкоуровневые средства

IT>Не знаю где это модно.
Как-будто форум не читаешь.


G>>4)Совсем не модно искать количественные характеристики программ и как-то работать с ними

IT>А где это модно?
Нигде, в том проблема.

G>>Причем индустрия предлагает все это, но далеко не все хотят пользоваться.

IT>Раз не хотят, значит им не нужно.



G>>>>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью".

IT>>>Так не бывает. Факторы есть, а корреляции нет
G>>Бывает.
IT>Не бывает. Законы сохранения, точнее закон равновесия, не обманешь.
Равновесия и сохранения чего?
Ты же сам был против формализации понятия "сложности".


IT>>>Есть вполне объективная сложность — сложность понимания решаемой задачи.

G>>Думаешь таковая сложность не присутствует у электронщиков? Или у любых других инженеров?

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

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

IT>>>В программировании для управления такой сложностью как раз в обсуждаемом контексте используются методологии из серии XP и Agile. Что-то подобное есть у электронщиков?

G>>Хм... а что такое XP и Agile, если отбросить написание кода?
G>>1)Частые поставки
G>>2)Приемочные тесты
G>>и собственно все...
G>>Думаешь у электронщиков такого нет?
G>>Только для "частых поставок" используются не готовые изделия, а средства моделирования (чуть более чем все — компьютерные).
IT>И какой из этого следует вывод?
Выводы сам делай, ты же доказывал что инженерия в минкроэлектронике сильно отличается от программирования.
Re[23]: Не, программист - не инженер
От: hardcase Пират http://nemerle.org
Дата: 28.11.10 09:17
Оценка: +2
Здравствуйте, gandjustas, Вы писали:

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

G>Конечно, зачастую сложность выносят на уровень прошивки, её поменять легче. Кроме того зачастую присутствует неопределенность в том окружении где будет работать изделие.

Т.е. сваливают работу с неопределенностью на программистов.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[23]: Не, программист - не инженер
От: IT Россия linq2db.com
Дата: 28.11.10 18:46
Оценка:
Здравствуйте, gandjustas, Вы писали:

IT>>>>Не важно как это называется. Важно, что в электронике требования обязаны быть более чётко формализированы.

G>>>Кому обязаны?
IT>>Здравому смыслу.
G>А чем разработка ПО хуже? Там меньше здравого смысла?

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

G>>>У программистов при этом:

G>>>1)Очень модно изобретать велосипеды
IT>>Потому что велосипеды каждый раз нужны с чуть более другими характеристиками.
G>Наверное считают что нужны велосипеды с другими характеристиками.

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

G>>>2)Очень модно использовать низкоуровневые средства

IT>>Не знаю где это модно.
G>Как-будто форум не читаешь.

Ну так просвети.

G>>>4)Совсем не модно искать количественные характеристики программ и как-то работать с ними

IT>>А где это модно?
G>Нигде, в том проблема.

Значит никому не нужно

G>>>Причем индустрия предлагает все это, но далеко не все хотят пользоваться.

IT>>Раз не хотят, значит им не нужно.
G>

Что смешного?

G>>>>>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью".

IT>>>>Так не бывает. Факторы есть, а корреляции нет
G>>>Бывает.
IT>>Не бывает. Законы сохранения, точнее закон равновесия, не обманешь.
G>Равновесия и сохранения чего?

Сохранения сложности, чего же ещё.

G>Ты же сам был против формализации понятия "сложности".


А где я за?

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

G>Конечно, зачастую сложность выносят на уровень прошивки, её поменять легче. Кроме того зачастую присутствует неопределенность в том окружении где будет работать изделие.

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

IT>>И какой из этого следует вывод?

G>Выводы сам делай, ты же доказывал что инженерия в минкроэлектронике сильно отличается от программирования.

В определённом смысле, конечно, отличается и странно, что ты не можешь увидеть эти различия. Ну давай вот такой пример.

Когда у Тойты Королы возникают проблемы с тормозами, то производитель, чтобы пофиксить эту проблему, вынужден отозвать все машины и терпит при этом колоссальные убытки. Когда проблема возникает в Microsoft Windows 7, то Microsoft тупо выпускает очередной пач и фиксит все имеющиеся в мире экземпляры Windows 7 без каких-либо существенных потерь. О чём это говорит? Лично мне это говорит о том, что цена ошибки и модификации уже работающего ПО мизирна в сравнении с ошибками в и модификацией уже работающего железа. Так или иначе это понимают все, включая заказчиков ПО. Поэтому, ситуация в программировании "- Жора! Жарьте рыбу. — Так рыбы нет! — Жора, вы жарьте! Рыба будет." обычная и я бы даже сказал типичная. Бизнесу гораздо проще примерять на себя полуготовый сюртук и заканчивать его внося корректировки по ходу дела. Всё это выглядит примерно вот так, но, если это работает, то кого это волнует. Лишь бы те, кто строит такое ПО сами понимали, что они делают и как и поменьше бы сравнивали себя с электронщиками и другой инженерией.
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: Не, программист - не инженер
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 28.11.10 19:51
Оценка:
Здравствуйте, IT, Вы писали:

IT>Когда у Тойты Королы возникают проблемы с тормозами, то производитель, чтобы пофиксить эту проблему, вынужден отозвать все машины и терпит при этом колоссальные убытки. Когда проблема возникает в Microsoft Windows 7, то Microsoft тупо выпускает очередной пач и фиксит все имеющиеся в мире экземпляры Windows 7 без каких-либо существенных потерь. О чём это говорит? Лично мне это говорит о том, что цена ошибки и модификации уже работающего ПО мизирна в сравнении с ошибками в и модификацией уже работающего железа.

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

IT>Так или иначе это понимают все, включая заказчиков ПО.

Ровно обратную ситуацию наблюдаю.

IT>Поэтому, ситуация в программировании "- Жора! Жарьте рыбу. — Так рыбы нет! — Жора, вы жарьте! Рыба будет." обычная и я бы даже сказал типичная.

Мне кажется ты путаешь позицию сейлзов\менеджеров и заказчиков.
Re[25]: Не, программист - не инженер
От: IT Россия linq2db.com
Дата: 28.11.10 22:06
Оценка:
Здравствуйте, gandjustas, Вы писали:

IT>>Когда у Тойты Королы возникают проблемы с тормозами, то производитель, чтобы пофиксить эту проблему, вынужден отозвать все машины и терпит при этом колоссальные убытки. Когда проблема возникает в Microsoft Windows 7, то Microsoft тупо выпускает очередной пач и фиксит все имеющиеся в мире экземпляры Windows 7 без каких-либо существенных потерь. О чём это говорит? Лично мне это говорит о том, что цена ошибки и модификации уже работающего ПО мизирна в сравнении с ошибками в и модификацией уже работающего железа.

G>Ну так с этого вроде и начали. Причем ты говорил что разработка ПО несет большую сложность. А получается наоборот.

Наоборот — это для заказчика/клиента. А для программиста это думать о том, чтобы не навредить, не сломать, соответствующим образом построить архитектуру. Или ты думаешь всё это даётся бесплатно?

IT>>Так или иначе это понимают все, включая заказчиков ПО.

G>Ровно обратную ситуацию наблюдаю.

Не повезло.

IT>>Поэтому, ситуация в программировании "- Жора! Жарьте рыбу. — Так рыбы нет! — Жора, вы жарьте! Рыба будет." обычная и я бы даже сказал типичная.

G>Мне кажется ты путаешь позицию сейлзов\менеджеров и заказчиков.

Какая разница чья это позиция? Ситуация типичная.
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Не, программист - не инженер
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 28.11.10 22:19
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>>>Когда у Тойты Королы возникают проблемы с тормозами, то производитель, чтобы пофиксить эту проблему, вынужден отозвать все машины и терпит при этом колоссальные убытки. Когда проблема возникает в Microsoft Windows 7, то Microsoft тупо выпускает очередной пач и фиксит все имеющиеся в мире экземпляры Windows 7 без каких-либо существенных потерь. О чём это говорит? Лично мне это говорит о том, что цена ошибки и модификации уже работающего ПО мизирна в сравнении с ошибками в и модификацией уже работающего железа.

G>>Ну так с этого вроде и начали. Причем ты говорил что разработка ПО несет большую сложность. А получается наоборот.

IT>Наоборот — это для заказчика/клиента. А для программиста это думать о том, чтобы не навредить, не сломать, соответствующим образом построить архитектуру. Или ты думаешь всё это даётся бесплатно?

Вот уже интереснее. Можешь формализовать как "не навредить, не сломать, соответствующим образом построить архитектуру" и сколько это стоит?


IT>>>Так или иначе это понимают все, включая заказчиков ПО.

G>>Ровно обратную ситуацию наблюдаю.
IT>Не повезло.
"Ситуация типичная" (С)

IT>>>Поэтому, ситуация в программировании "- Жора! Жарьте рыбу. — Так рыбы нет! — Жора, вы жарьте! Рыба будет." обычная и я бы даже сказал типичная.

G>>Мне кажется ты путаешь позицию сейлзов\менеджеров и заказчиков.
IT>Какая разница чья это позиция? Ситуация типичная.
Вообще говоря большая. Будучи ближе к "бизнесу" я начал по-другому подходить к разработке. Лишние уровни косвенности между заказчиком и разработчиком зачастую идут во вред разработке и создают довольно абсурдные ситуации.
Re[8]: Не, программист - не инженер
От: Кэр  
Дата: 28.11.10 23:01
Оценка:
Здравствуйте, FR, Вы писали:

Кэр>>Лично мне башню оторвало надолго серии, где показывали что такое на самом деле LINQ, что такое монады и как они тут рулят, как оно оборачивается в Rx, какие есть области применения. Я тут заобщался с Эриком Мейером (мега-дядька!) он утверждает и показывает, что Rx на самом деле решает проблему сложности параллельного программирования — я это хотел тут выложить и обсудить, просто руки еще не дошли.


FR>Это все было в 70-ых — 80ых годах.


Все остальное уже более-менее обсудили. Но вот это интересно. Что было в 70-80? Rx как LINQ поверх push based collections — это свеженький концепт. С новыми необычными применениями. Или вы можете показать, что это не так?
Re[27]: Не, программист - не инженер
От: IT Россия linq2db.com
Дата: 29.11.10 03:03
Оценка:
Здравствуйте, gandjustas, Вы писали:

IT>>Наоборот — это для заказчика/клиента. А для программиста это думать о том, чтобы не навредить, не сломать, соответствующим образом построить архитектуру. Или ты думаешь всё это даётся бесплатно?

G>Вот уже интереснее. Можешь формализовать как "не навредить, не сломать, соответствующим образом построить архитектуру" и сколько это стоит?

Зачем? Что ты с этой формализацией собираешься делать?

IT>>>>Поэтому, ситуация в программировании "- Жора! Жарьте рыбу. — Так рыбы нет! — Жора, вы жарьте! Рыба будет." обычная и я бы даже сказал типичная.

G>>>Мне кажется ты путаешь позицию сейлзов\менеджеров и заказчиков.
IT>>Какая разница чья это позиция? Ситуация типичная.
G>Вообще говоря большая. Будучи ближе к "бизнесу" я начал по-другому подходить к разработке. Лишние уровни косвенности между заказчиком и разработчиком зачастую идут во вред разработке и создают довольно абсурдные ситуации.

Будучи ближе к бизнесу я понял что бизнесу вообще начхать на любые уровни не только косвенности, но и всего остального. Бизнесу нужен результат и больше ничего.
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Не, программист - не инженер
От: FR  
Дата: 29.11.10 09:13
Оценка:
Здравствуйте, Кэр, Вы писали:

FR>>Это все было в 70-ых — 80ых годах.


Кэр>Все остальное уже более-менее обсудили. Но вот это интересно. Что было в 70-80? Rx как LINQ поверх push based collections — это свеженький концепт. С новыми необычными применениями. Или вы можете показать, что это не так?


Концепции лежащие в их основе были чем-то новым эти самые 80 а не сейчас, и уже в конце 80 начале 90 воплотилось в таких языках как
Haskell и Clean.
Re[18]: Не, программист - не инженер
От: Eye of Hell Россия eyeofhell.habr.ru
Дата: 29.11.10 12:49
Оценка:

Любая программа, увы, работает не в вакууме, её конечная цель — автоматизация действий заказчика — того самого бардака


Подскажите старику, игра Angry Birds для iPhone — какие действия и какого заказчика автоматизирует? Или это не "программа"? Или под "программой" вы понимаете что-то специфическое — если да, то что?
Re[19]: Не, программист - не инженер
От: Sinix  
Дата: 29.11.10 13:13
Оценка:
Здравствуйте, Eye of Hell, Вы писали:

Любая программа, увы, работает не в вакууме, её конечная цель — автоматизация действий заказчика — того самого бардака


EOH>Подскажите старику, игра Angry Birds для iPhone — какие действия и какого заказчика автоматизирует? Или это не "программа"? Или под "программой" вы понимаете что-то специфическое — если да, то что?


В ветке вроде как говорят о разработке; подразумевалось заказное ПО. Можно было бы уточнить, казалось, что контекста очевидно.

И да, в игрострое бардак тоже присутствует; обусловлен практически тем же: необходимостью сделать успешный продукт самнезнаюкак. Только акцент смещён с "эффективно реализовать заранее неизвестные требюования" на "как-то отличиться от сотни клонов + понравиться игрокам".
Re[20]: Не, программист - не инженер
От: Eye of Hell Россия eyeofhell.habr.ru
Дата: 29.11.10 13:27
Оценка:

В ветке вроде как говорят о разработке; подразумевалось заказное ПО.


Я прекрасно все понимаю, меня просто актуальная терминология интересует. Я правильно понимаю, что если программа "разрабатывается" — то это заказное ПО? И "заказное" тут подразумевается автоматизация бизнес-процессов, так как если я закажу, например, игрушку или коробочный продукт — то там не будет "автоматизации действий заказчика"?
Re[21]: Не, программист - не инженер
От: Sinix  
Дата: 29.11.10 13:55
Оценка:
Здравствуйте, Eye of Hell, Вы писали:

EOH>

В ветке вроде как говорят о разработке; подразумевалось заказное ПО.


EOH>Я прекрасно все понимаю, меня просто актуальная терминология интересует. Я правильно понимаю, что если программа "разрабатывается" — то это заказное ПО? И "заказное" тут подразумевается автоматизация бизнес-процессов, так как если я закажу, например, игрушку или коробочный продукт — то там не будет "автоматизации действий заказчика"?


Ну...

Всё что я хотел сказать, я сказал на тут
Автор: Sinix
Дата: 26.11.10
. Всё последующее — мы начали с Эдисона и Теслы, а закончили тем, что все неправы.

В процитированном посте я отвечал на

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

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

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

Ещё одна проблема: я неоднократно сталкивался с тем, что сам заказчик не понимает, чего он хочет и как работает автоматизируемая деятельность. Или предметная область слишком сложна и сама по себе непредсказуема. Или, самое печальное — зачастую люди не хотят разбираться и реагируют кране агрессивно на любые расспросы. У Брукса в "Design on Design" мне только вчера попалась подходящая цитата:

Then, slowly, I came to realize that the most useful service
I was performing for my client was helping him decide what he
really wanted.

Так что да, бардак
Re[10]: Не, программист - не инженер
От: Кэр  
Дата: 29.11.10 14:08
Оценка: +1
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Кэр, Вы писали:


FR>>>Это все было в 70-ых — 80ых годах.


Кэр>>Все остальное уже более-менее обсудили. Но вот это интересно. Что было в 70-80? Rx как LINQ поверх push based collections — это свеженький концепт. С новыми необычными применениями. Или вы можете показать, что это не так?


FR>Концепции лежащие в их основе были чем-то новым эти самые 80 а не сейчас, и уже в конце 80 начале 90 воплотилось в таких языках как

FR>Haskell и Clean.

Ах концепции... Да и вообще архитектура процессора никак не поменялась, так что ничто не ново под луной, ага?

Ну и Эрик Мейер — это один их архитекторов Хаскела. Я ему верю больше, когда он говорит, что это новый концепт, чем вам
Re[11]: Не, программист - не инженер
От: Кэр  
Дата: 29.11.10 15:14
Оценка:
Кэр>Ну и Эрик Мейер — это один их архитекторов Хаскела. Я ему верю больше, когда он говорит, что это новый концепт, чем вам

Но если у вас есть что по существу сказать, а не просто бросить свой авторитет как аргумент — будет интересно послушать
Re[22]: Не, программист - не инженер
От: Eye of Hell Россия eyeofhell.habr.ru
Дата: 29.11.10 15:58
Оценка:

В процитированном посте я отвечал на ... и пытался донести, что поскольку сама предметная область нечёткая, то и формироваться/формализоваться нечему. Ещё одна проблема: я неоднократно сталкивался с тем, что сам заказчик не понимает, чего он хочет и как работает автоматизируемая деятельность. Или предметная область слишком сложна и сама по себе непредсказуема. Или, самое печальное — зачастую люди не хотят разбираться и реагируют кране агрессивно на любые расспросы.


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

Что характерно — уровень бардака (чудовищный) примерно одинаков. И если про заказной сайт для автоматизации добавления заказа в базу данных можно все свалить на заказчика и постоянно меняющиеся требования — то что делать с остальными областями? У коробочных продуктов-то заказчика как такового нету. И требования там разработчик сам себе ставит. А код гниет точно также. И сроки срываются. И через раз все заново переписывается. И парк велосипедов как в парке Горького. И неподдерживаемое, неподдающееся рефакторингу спагетти точно так же пишут.

Почему? Я не знаю .
Re[23]: Не, программист - не инженер
От: Sinix  
Дата: 29.11.10 16:39
Оценка: +1
Здравствуйте, Eye of Hell, Вы писали:

EOH>Что характерно — уровень бардака (чудовищный) примерно одинаков. И если про заказной сайт для автоматизации добавления заказа в базу данных можно все свалить на заказчика и постоянно меняющиеся требования — то что делать с остальными областями? У коробочных продуктов-то заказчика как такового нету. И требования там разработчик сам себе ставит. А код гниет точно также. И сроки срываются. И через раз все заново переписывается. И парк велосипедов как в парке Горького. И неподдерживаемое, неподдающееся рефакторингу спагетти точно так же пишут.


EOH>Почему? Я не знаю .


Вы сами всё сказали

Я ещё в первом посте озвучил 2 основные причины:

1. Сложность задачи несопоставима с выделенными ресурсами.

Фактически, создавая ПО, мы пытаемся заставить _детерминированную_ машину заставить имитировать процессы _реального_ мира при минимальном участии человека. Там, где у нас сами процессы формализованы — круглое щастье.

Там, где нет — нет. В этом случае мы одновременно с разработкой ПО пытаемся изучить реальный мир (явно или неявно — неважно). Ключевая фраза — мы не знаем, что нам нужно делать. Даже с приблизительной определённостью. Точнее, можем узнать, но потребные ресурсы будут сопоставимы с затратами на создание действующей модели — ПО. Вот в этом и заключается вся сложность.

И подвижек тут не предвидится: если мы сделаем чугуневое ПО, нам придётся делегировать ответственность за неопределённость уровнем выше. В старых добрых 80х, когда люди ещё временами верили в разумность происходящего, была надежда на успех АРМ: дескать, машина нудятину возьмёт на себя, оставив человеку должность рулевого. Ничего не вышло по 3м причинам:
1.1. Работы меньше не становится. Если удастся частично разгрузить человека, на него неизбежно взвалят дополнительные обязанности. И да, копир с автоподатчиком может оказаться дороже оператора копировальной машины.
1.2. Там, где задача выходит за пределы возможностей одного человека, необходимо взаимодействовать. Насколько люди к этому способны (в долговременной перспективе, да ещё и в количестве большем трёх), думаю, объяснять не надо.
1.3. Человек — не машина: он не может постоянно и с должной эффективностью работать мозгом для АРМ. Увы, чтобы это обнаружить надо было дождаться, пока оператор ЭВМ не стал синонимом для распознавателя капч.

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

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

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

Кстати, где-то попадался великолепный англоязычный пост, в котором описывался объём затрат для попадания нескольких строчек API в релизный код. Никто ничего такого не помнит?
Re[11]: Не, программист - не инженер
От: FR  
Дата: 29.11.10 18:33
Оценка: +1
Здравствуйте, Кэр, Вы писали:

Кэр>Ах концепции... Да и вообще архитектура процессора никак не поменялась, так что ничто не ново под луной, ага?


Я же пишу было реализовано в 90-ых.
До этого без проблем работал как паттерн в ML образных.

Кэр>Ну и Эрик Мейер — это один их архитекторов Хаскела. Я ему верю больше, когда он говорит, что это новый концепт, чем вам


Ну не будет же он говорить что повторяет давно известное, и им же самим уже реализованное в другом языке, не по микросовтовски это
Re[12]: Не, программист - не инженер
От: Кэр  
Дата: 29.11.10 23:29
Оценка:
Здравствуйте, FR, Вы писали:

FR>Я же пишу было реализовано в 90-ых.

FR>До этого без проблем работал как паттерн в ML образных.

Ну то есть вас не затруднит показать библиотеку-аналог Rx, например, в Хаскеле датированный 70-80 прошлого века? Или 90-х, бог с вами. Именно Rx, а не какую-то библиотеку со словом "монада" внутри.

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


О, срывают покровы! Это всегда интересно. Жду ответа с нетерпением.
Re[13]: Не, программист - не инженер
От: FR  
Дата: 30.11.10 07:06
Оценка:
Здравствуйте, Кэр, Вы писали:


Кэр>Ну то есть вас не затруднит показать библиотеку-аналог Rx, например, в Хаскеле датированный 70-80 прошлого века? Или 90-х, бог с вами. Именно Rx, а не какую-то библиотеку со словом "монада" внутри.


Затруднит Хаскеля к сожалению тогда еще не было.
Но реактивное программирование уже было:

http://www-sop.inria.fr/mimosa/rp/generalPresentation/index.html

The project, previously called RC project, has started in 1988


C FRP мекня склероз подвел это все-таки конец 90-ых:

Reactive Programming in Standard ML

Ну и даже товарищи работающие в империи зла в 2001 году этим же занимались:
http://www.haskell.org/yale/papers/haskellworkshop01/index.html
Genuinely Functional User Interfaces


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


Кэр>О, срывают покровы! Это всегда интересно. Жду ответа с нетерпением.


Побольше побольше яду!
Re[14]: Не, программист - не инженер
От: Кэр  
Дата: 30.11.10 07:29
Оценка:
Здравствуйте, FR, Вы писали:

Кэр>>Ну то есть вас не затруднит показать библиотеку-аналог Rx, например, в Хаскеле датированный 70-80 прошлого века? Или 90-х, бог с вами. Именно Rx, а не какую-то библиотеку со словом "монада" внутри.


FR>Затруднит Хаскеля к сожалению тогда еще не было.

FR>Но реактивное программирование уже было:
FR>http://www-sop.inria.fr/mimosa/rp/generalPresentation/index.html
FR>

FR>The project, previously called RC project, has started in 1988

FR>C FRP мекня склероз подвел это все-таки конец 90-ых:
FR>Reactive Programming in Standard ML

FR>Ну и даже товарищи работающие в империи зла в 2001 году этим же занимались:

FR>http://www.haskell.org/yale/papers/haskellworkshop01/index.html
FR>Genuinely Functional User Interfaces

Извините, видимо это моя ошибка. Я указал, что нужно именно Rx как LINQ поверх push based collections — в этом вся соль. А потом сказал, что нужна не просто библиотека, где есть слово "монада". Забыл уточнить, что нужна не просто библиотека, которая тоже называется reactive Но как вы понимаете перечисление всех отрицаний может занять довольно долгое время.

А если серьезно, то все эти stop(), singal(), awaits(), merge() и прочее — это страх божий. И нифига это не тоже самое, как вы не вертите. Код на Rx получается гораздо более лаконичный и понятный.

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

Кэр>>О, срывают покровы! Это всегда интересно. Жду ответа с нетерпением.
FR>Побольше побольше яду!

А вы ожидали, что яд — это только ваш скилл, другим совершенно недоступный? Вы не находите это несколько наивным?
Re[15]: Не, программист - не инженер
От: FR  
Дата: 30.11.10 07:53
Оценка:
Здравствуйте, Кэр, Вы писали:


Кэр>Извините, видимо это моя ошибка. Я указал, что нужно именно Rx как LINQ поверх push based collections — в этом вся соль. А потом сказал, что нужна не просто библиотека, где есть слово "монада". Забыл уточнить, что нужна не просто библиотека, которая тоже называется reactive Но как вы понимаете перечисление всех отрицаний может занять довольно долгое время.


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

Кэр>А если серьезно, то все эти stop(), singal(), awaits(), merge() и прочее — это страх божий. И нифига это не тоже самое, как вы не вертите. Код на Rx получается гораздо более лаконичный и понятный.


В хаскелевских уже давно все в монады запаковано http://conal.net/fran/tutorial.htm
Удобные реактивные библиотеки совсем не новинка, даже питоновскому Trellis уже года три наверно.

Кэр>А вы ожидали, что яд — это только ваш скилл, другим совершенно недоступный? Вы не находите это несколько наивным?


Нет до вас мне далеко, так что не претендую, долго не смогу в таком тоне.
Re[16]: Не, программист - не инженер
От: Кэр  
Дата: 30.11.10 13:55
Оценка:
Здравствуйте, FR, Вы писали:

FR>Да я понял пуговицы обязательно должны быть перламутровые, извините не учел-с


Нет, вы не поняли Я здесь вижу главным то, что Rx это именно язык запросов поверх push based collections, которые являются дуальными к обычным pull based collections. Просто это получается чертовски удобно. И именно этого я не вижу в ваших примерах.

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

Кэр>>А если серьезно, то все эти stop(), singal(), awaits(), merge() и прочее — это страх божий. И нифига это не тоже самое, как вы не вертите. Код на Rx получается гораздо более лаконичный и понятный.


FR>В хаскелевских уже давно все в монады запаковано http://conal.net/fran/tutorial.htm

FR>Удобные реактивные библиотеки совсем не новинка, даже питоновскому Trellis уже года три наверно.

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

Кэр>>А вы ожидали, что яд — это только ваш скилл, другим совершенно недоступный? Вы не находите это несколько наивным?

FR>Нет до вас мне далеко, так что не претендую, долго не смогу в таком тоне.

Да я такой тон выдерживаю только в разговоре, где основным аргументом является личный авторитет. Нет никакого уважения к личным авторитетам — вот что вы поделаете?
Re[17]: Не, программист - не инженер
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 30.11.10 14:05
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Нет, вы не поняли Я здесь вижу главным то, что Rx это именно язык запросов поверх push based collections, которые являются дуальными к обычным pull based collections. Просто это получается чертовски удобно. И именно этого я не вижу в ваших примерах.


tcl/tk?
Re[18]: Не, программист - не инженер
От: Кэр  
Дата: 30.11.10 14:29
Оценка:
Здравствуйте, lomeo, Вы писали:

Кэр>>Нет, вы не поняли Я здесь вижу главным то, что Rx это именно язык запросов поверх push based collections, которые являются дуальными к обычным pull based collections. Просто это получается чертовски удобно. И именно этого я не вижу в ваших примерах.


L>tcl/tk?


Вас не затруднит привести аналог вот этого примера? Ну или выберите другой пример, который вы считаете показательным.
Re[19]: Не, программист - не инженер
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 30.11.10 14:45
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Вас не затруднит привести аналог вот этого примера? Ну или выберите другой пример, который вы считаете показательным.


Затруднит
Re[20]: Не, программист - не инженер
От: night beast СССР  
Дата: 02.12.10 06:42
Оценка:
Здравствуйте, lomeo, Вы писали:

Кэр>>Вас не затруднит привести аналог вот этого примера? Ну или выберите другой пример, который вы считаете показательным.


L>Затруднит


тут хотелось бы заметить, что язык позволяет такое сделать.
проблема в том что кто знает tcl, не знает rx, а кто знает rx, тому не нужен tcl.
как-то так
Re[21]: Не, программист - не инженер
От: Кэр  
Дата: 02.12.10 22:16
Оценка:
Здравствуйте, night beast, Вы писали:

NB>тут хотелось бы заметить, что язык позволяет такое сделать.

NB>проблема в том что кто знает tcl, не знает rx, а кто знает rx, тому не нужен tcl.
NB>как-то так

Таки очень хотелось бы увидеть пример на tcl Вас не затруднит?
Re[22]: Не, программист - не инженер
От: night beast СССР  
Дата: 03.12.10 05:51
Оценка:
Здравствуйте, Кэр, Вы писали:

NB>>тут хотелось бы заметить, что язык позволяет такое сделать.

NB>>проблема в том что кто знает tcl, не знает rx, а кто знает rx, тому не нужен tcl.
NB>>как-то так

Кэр>Таки очень хотелось бы увидеть пример на tcl Вас не затруднит?


ок. код
class GroupBy_Simple
{
    static IEnumerable<ConsoleKeyInfo> KeyPresses()
    {
        for (; ; )
        {
            var currentKey = Console.ReadKey(true);

            if (currentKey.Key == ConsoleKey.Enter)
                yield break;
            else
                yield return currentKey;
        }
    }
    static void Main()
    {
        var timeToStop = new ManualResetEvent(false);
        var keyPresses = KeyPresses().ToObservable();

        var groupedKeyPresses =
            from k in keyPresses
            group k by k.Key into keyPressGroup
            select keyPressGroup;

        Console.WriteLine("Press Enter to stop.  Now bang that keyboard!");

        groupedKeyPresses.Subscribe(keyPressGroup =>
        {
            int numberPresses = 0;

            keyPressGroup.Subscribe(keyPress =>
            {
                Console.WriteLine(
                    "You pressed the {0} key {1} time(s)!",
                    keyPress.Key,
                    ++numberPresses);
            },
            () => timeToStop.Set());
        });

        timeToStop.WaitOne();
    }
}

объясни что и как там происходит, и я попробую реализовать это на тикле ( хотя не прогал на нем 100 лет )

PS: не знаю ни Rx, ни шарпа, так что если можно, подробнее объясняй
Re[23]: Не, программист - не инженер
От: Кэр  
Дата: 03.12.10 10:20
Оценка:
Здравствуйте, night beast, Вы писали:

NB>ок. код

class GroupBy_Simple
{
    // Получаем ввод с клавиатуры в виде псевдо-бесконечной последовательности клавиш.
    // Enter прерывает эту последовательность.
    static IEnumerable<ConsoleKeyInfo> KeyPresses()
    {
        for (; ; )
        {
            var currentKey = Console.ReadKey(true);

            if (currentKey.Key == ConsoleKey.Enter)
                yield break;
            else
                yield return currentKey;
        }
    }
    static void Main()
    {
        // Определяем флаг, который будет держать основной поток, пока мы тарабаним по клавиатуре.
        var timeToStop = new ManualResetEvent(false);

        // Используя дуальность коллекции переворачиваем блокирующую последовательность в поток
        // событий. С IEnumerable тоже все будет работать, но не будет асинхронного вывода, все 
        // будет распечатано в самом конце после финального Enter.
        var keyPresses = KeyPresses().ToObservable();

        // Используя LINQ поверх push based collections опредеяем, что нас интересует не поток 
        // событий "нажатия на клавиши" - мы хотим, чтобы этот поток был сгруппирован по нажатым 
        // клавишам. И мы подпишемся уже на группы событий. Могли бы еще, например, отфильтровать,
        // или сджойнить с другими событиями, или...
        var groupedKeyPresses =
            from k in keyPresses
            group k by k.Key into keyPressGroup
            select keyPressGroup;

        Console.WriteLine("Press Enter to stop.  Now bang that keyboard!");

        // Поехали. Для каждой группы определим делегат с внутренним состоянием, который будет вести 
        // учет текущего количества элементов в группе.
        groupedKeyPresses.Subscribe(keyPressGroup =>
        {
            int numberPresses = 0;

            // Для каждого события в группе будем распечатывать уведомление на экран и увеличивать счетчик заодно.
            keyPressGroup.Subscribe(keyPress =>
            {
                Console.WriteLine(
                    "You pressed the {0} key {1} time(s)!",
                    keyPress.Key,
                    ++numberPresses);
            },

            //  Когда события иссякнут (будет нажата клавиша Enter) - отпустить флаг блокирующий основной поток
            () => timeToStop.Set());
        });

        // Подождать, пока клавиша Enter будет нажата.
        timeToStop.WaitOne();
    }
}


NB>объясни что и как там происходит, и я попробую реализовать это на тикле ( хотя не прогал на нем 100 лет )

NB>PS: не знаю ни Rx, ни шарпа, так что если можно, подробнее объясняй

Жду вашего кода. Если нужно еще подробнее — не стесняйтесь спрашивать. Мне интересно увидеть вариант на tcl
Re[24]: Не, программист - не инженер
От: night beast СССР  
Дата: 03.12.10 10:34
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Здравствуйте, night beast, Вы писали:


NB>>ок. код

Кэр>
Кэр>class GroupBy_Simple
Кэр>{
Кэр>    // Получаем ввод с клавиатуры в виде псевдо-бесконечной последовательности клавиш.
Кэр>    // Enter прерывает эту последовательность.
Кэр>    static IEnumerable<ConsoleKeyInfo> KeyPresses()
Кэр>    {
Кэр>        for (; ; )
Кэр>        {
Кэр>            var currentKey = Console.ReadKey(true);

Кэр>            if (currentKey.Key == ConsoleKey.Enter)
Кэр>                yield break;
Кэр>            else
Кэр>                yield return currentKey;
Кэр>        }
Кэр>    }
Кэр>    static void Main()
Кэр>    {
Кэр>        // Определяем флаг, который будет держать основной поток, пока мы тарабаним по клавиатуре.
Кэр>        var timeToStop = new ManualResetEvent(false);

Кэр>        // Используя дуальность коллекции переворачиваем блокирующую последовательность в поток
Кэр>        // событий. С IEnumerable тоже все будет работать, но не будет асинхронного вывода, все 
Кэр>        // будет распечатано в самом конце после финального Enter.
Кэр>        var keyPresses = KeyPresses().ToObservable();

Кэр>        // Используя LINQ поверх push based collections опредеяем, что нас интересует не поток 
Кэр>        // событий "нажатия на клавиши" - мы хотим, чтобы этот поток был сгруппирован по нажатым 
Кэр>        // клавишам. И мы подпишемся уже на группы событий. Могли бы еще, например, отфильтровать,
Кэр>        // или сджойнить с другими событиями, или...
Кэр>        var groupedKeyPresses =
Кэр>            from k in keyPresses
Кэр>            group k by k.Key into keyPressGroup
Кэр>            select keyPressGroup;

Кэр>        Console.WriteLine("Press Enter to stop.  Now bang that keyboard!");

Кэр>        // Поехали. Для каждой группы определим делегат с внутренним состоянием, который будет вести 
Кэр>        // учет текущего количества элементов в группе.
Кэр>        groupedKeyPresses.Subscribe(keyPressGroup =>
Кэр>        {
Кэр>            int numberPresses = 0;

Кэр>            // Для каждого события в группе будем распечатывать уведомление на экран и увеличивать счетчик заодно.
Кэр>            keyPressGroup.Subscribe(keyPress =>
Кэр>            {
Кэр>                Console.WriteLine(
Кэр>                    "You pressed the {0} key {1} time(s)!",
Кэр>                    keyPress.Key,
Кэр>                    ++numberPresses);
Кэр>            },

Кэр>            //  Когда события иссякнут (будет нажата клавиша Enter) - отпустить флаг блокирующий основной поток
Кэр>            () => timeToStop.Set());
Кэр>        });

Кэр>        // Подождать, пока клавиша Enter будет нажата.
Кэр>        timeToStop.WaitOne();
Кэр>    }
Кэр>}
Кэр>


NB>>объясни что и как там происходит, и я попробую реализовать это на тикле ( хотя не прогал на нем 100 лет )

NB>>PS: не знаю ни Rx, ни шарпа, так что если можно, подробнее объясняй

Кэр>Жду вашего кода. Если нужно еще подробнее — не стесняйтесь спрашивать.


нужно
интересует и как все происходит. то есть что и в какой последовательности вызывается при нажатии клавиши.
Re[25]: Не, программист - не инженер
От: Кэр  
Дата: 03.12.10 10:43
Оценка:
Здравствуйте, night beast, Вы писали:

NB>нужно

NB>интересует и как все происходит. то есть что и в какой последовательности вызывается при нажатии клавиши.

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

Но работает примерно так — Subscribe декларирует подписчик на сгенерированную цепочку событий. Сама цепочка нашими усилиями начинает ожидать нажатия клавиш и потом преобразует нажатия клавиш в нечто более удобное, с чем мы работаем уже в подписчике. В каком месте нужно еще подробнее?
Re[26]: Не, программист - не инженер
От: night beast СССР  
Дата: 03.12.10 11:00
Оценка:
Здравствуйте, Кэр, Вы писали:

NB>>нужно

NB>>интересует и как все происходит. то есть что и в какой последовательности вызывается при нажатии клавиши.

Кэр>Хм, не очень понимаю, как это влияет на семантику, чтобы переписать это на tcl, тем более что утверждается, что он умеет работать с запросами поверх цепочки событий.


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

Кэр>Но работает примерно так — Subscribe декларирует подписчик на сгенерированную цепочку событий. Сама цепочка нашими усилиями начинает ожидать нажатия клавиш и потом преобразует нажатия клавиш в нечто более удобное, с чем мы работаем уже в подписчике. В каком месте нужно еще подробнее?


извиняюсь за глупые вопросы, я сразу предупредил что с шарпом не знаком
твой запрос ждет пока ввод закончится, или уведомляет подписчиков по мере поступления данных?
что делает "group k by k.Key"? я правильно понимаю, что для каждой группы создается свой подписчик?
Re[27]: Не, программист - не инженер
От: Кэр  
Дата: 03.12.10 11:50
Оценка:
Здравствуйте, night beast, Вы писали:

Кэр>>Хм, не очень понимаю, как это влияет на семантику, чтобы переписать это на tcl, тем более что утверждается, что он умеет работать с запросами поверх цепочки событий.


NB>ты меня с кем-то путаешь. я сказал что это можно реализовать средствами языка.

NB>чтобы это сделать, мне нужно понять, какое поведение моделировать.

Ааа. Ну тогда мне сразу неинтересно. Вы ответили в ветке, в которой обсуждалось, что в Rx ничего нового нет. На просьбу показать где было — в конце концов договорились, что было в tcl. На просьбу показать как именно это было в tcl откликнулись вы. Этот код можно написать очень различными способами, благо сама программа несложная. Мне интересно было посмотреть на запросы к цепочке событий в другом языке, как было обещано.

Кэр>>Но работает примерно так — Subscribe декларирует подписчик на сгенерированную цепочку событий. Сама цепочка нашими усилиями начинает ожидать нажатия клавиш и потом преобразует нажатия клавиш в нечто более удобное, с чем мы работаем уже в подписчике. В каком месте нужно еще подробнее?


NB>извиняюсь за глупые вопросы, я сразу предупредил что с шарпом не знаком

NB>твой запрос ждет пока ввод закончится, или уведомляет подписчиков по мере поступления данных?

Уведомляет по мере.

NB>что делает "group k by k.Key"?


Описывает запрос к цепочке событий. Конкретно здесь декларируется, что события должны быть сгруппированы по нажатой клавише. После этой декларации мы будем работать с группами событий. Ключом каждой группы будет значение клавиши: "Q", "W", "E", "R", etc.

NB>я правильно понимаю, что для каждой группы создается свой подписчик?


Подписчик в виде лямбда-функции декларируется один раз, но он параметризирован группой событий.
Re[28]: Не, программист - не инженер
От: night beast СССР  
Дата: 03.12.10 12:27
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>>>Хм, не очень понимаю, как это влияет на семантику, чтобы переписать это на tcl, тем более что утверждается, что он умеет работать с запросами поверх цепочки событий.


NB>>ты меня с кем-то путаешь. я сказал что это можно реализовать средствами языка.

NB>>чтобы это сделать, мне нужно понять, какое поведение моделировать.

Кэр>Ааа. Ну тогда мне сразу неинтересно. Вы ответили в ветке, в которой обсуждалось, что в Rx ничего нового нет. На просьбу показать где было — в конце концов договорились, что было в tcl. На просьбу показать как именно это было в tcl откликнулись вы. Этот код можно написать очень различными способами, благо сама программа несложная. Мне интересно было посмотреть на запросы к цепочке событий в другом языке, как было обещано.


давайте не будем мне приписывать то, чего я не говорил. а говорил я, что это возможно сделать.
не более того.
Re[29]: Не, программист - не инженер
От: Кэр  
Дата: 03.12.10 13:08
Оценка:
Здравствуйте, night beast, Вы писали:

Кэр>>Ааа. Ну тогда мне сразу неинтересно. Вы ответили в ветке, в которой обсуждалось, что в Rx ничего нового нет. На просьбу показать где было — в конце концов договорились, что было в tcl. На просьбу показать как именно это было в tcl откликнулись вы. Этот код можно написать очень различными способами, благо сама программа несложная. Мне интересно было посмотреть на запросы к цепочке событий в другом языке, как было обещано.


NB>давайте не будем мне приписывать то, чего я не говорил. а говорил я, что это возможно сделать.

NB>не более того.

В таком случае ценность такого утверждения крайне невелика. Покажите мне язык, на котором этого нельзя сделать.
Re[30]: Не, программист - не инженер
От: night beast СССР  
Дата: 03.12.10 13:27
Оценка: -1
Здравствуйте, Кэр, Вы писали:

NB>>давайте не будем мне приписывать то, чего я не говорил. а говорил я, что это возможно сделать.

NB>>не более того.

Кэр>В таком случае ценность такого утверждения крайне невелика. Покажите мне язык, на котором этого нельзя сделать.


ну я как-бы писал ответ не тебе.
извини если задел твое чувство прекрасного...
Re[17]: Не, программист - не инженер
От: FR  
Дата: 05.12.10 18:34
Оценка: +1 -1
Здравствуйте, Кэр, Вы писали:

Кэр>Нет, вы не поняли Я здесь вижу главным то, что Rx это именно язык запросов поверх push based collections, которые являются дуальными к обычным pull based collections. Просто это получается чертовски удобно. И именно этого я не вижу в ваших примерах.


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


Смотрел пример ниже, возможно я блаб, но ничего чем можно восхитится не увидел.
Возможно на фоне C# это что-то, на фоне функциональщины похоже на обычный код.
Re: Инструменты
От: Klatu  
Дата: 06.12.10 06:38
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>А важно то, собственно, к чему это я? А важно то, что не бывает универсальных инструментов. Универсальный инструмент противоречил бы законам природы, так же, как универсальный растворитель — его просто не в чем было бы хранить!


Инструменты нужны не универсальные, а адаптируемые. Мы же все-таки с софтом имеем дело, а не со стальными кусачками.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[18]: Не, программист - не инженер
От: Кэр  
Дата: 13.12.10 11:45
Оценка: +1
Здравствуйте, FR, Вы писали:

FR>Смотрел пример ниже, возможно я блаб, но ничего чем можно восхитится не увидел.

FR>Возможно на фоне C# это что-то, на фоне функциональщины похоже на обычный код.

У меня и не стояло задачи вас восхитить Мне было интересно, сможете ли вы подтвердить свои слова, что это было раньше — но так и не дождался. Без этого ваше аторитетное мнение — мне не очень интересно, уж извините.
Re[19]: Не, программист - не инженер
От: FR  
Дата: 14.12.10 16:44
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>У меня и не стояло задачи вас восхитить Мне было интересно, сможете ли вы подтвердить свои слова, что это было раньше — но так и не дождался. Без этого ваше аторитетное мнение — мне не очень интересно, уж извините.


Мне все же интересно что ты там нового и потрясающего увидел, выше ты писал:

Лично мне башню оторвало надолго серии, где показывали что такое на самом деле LINQ, что такое монады и как они тут рулят, как оно оборачивается в Rx, какие есть области применения. Я тут заобщался с Эриком Мейером (мега-дядька!) он утверждает и показывает, что Rx на самом деле решает проблему сложности параллельного программирования — я это хотел тут выложить и обсудить, просто руки еще не дошли.


как руки дойдут, дай пожалуйста ссылку сюда.
Re[13]: Не, программист - не инженер
От: vdimas Россия  
Дата: 14.12.10 19:37
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Ну а чем деятельность программиста отличается от деятельности микроэлектронщика?


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

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

Хотя... "серьезный" софт делают не так много производителей, и этот серьезный софт, что логично, стоит довольно дешево, особенно оптом (вспомним подписку MSDN). Зато всякие поделки по-месту из разряда "решения уровня предприятия" толкаются за десятки-сотни тысяч аж бегом.

K>И те и другие переводят неформальные требования в формальное описание автомата, решающего поставленную задачу. Единственная разница — тиражирование автоматов, которые разрабатывают программисты тривиально, а значит в программировании есть только R&D а вся деятельность связанная с налаживанием серийного производстав отсутствует в принципе.


Как правильно заметили где-то недалеко — компиляция/сборка конечного продукта/пакета и есть аналог "серийного" производства. И деятельность по её налаживанию вовсе не бесплатна. Хотя, ты совершенно прав, вложения на разработку софта относительно невелики. Проблема лишь в том, все все делают одно и то же, деля небесконечный пирог. И за рамки разумной рыночной конкуренции тут все выскочило еще в конце 80-х. Современная "переконкуренция" — не меньший вред, чем отсутствие конкуренции вообще, ибо пользователю постоянно подсовывают сырое г-но, и это уже не считается чем-то постыдным. Разве мы обсуждаем со смешком в курилках какую-нить знаменитую ошибку какого-нить известного пакета, как это было лет 20 назад? Да сейчас их сотни и тысячи ошибок регулярно в автообновлениях исправляется, это сегодня норма...

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


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

ИМХО, вот этому современному романтизму в IT, когда небольшая группа энтузиастов может что-то толковое сделать с 0-ля осталось не так много лет. Так что, если у кого есть какие идеи — лучше поторопиться. Через пару десятков лет поздновато будет. Как поздно сейчас разрабатывать компьютеры в одиночку.
Re: Инструменты
От: Visor2004  
Дата: 14.12.10 21:38
Оценка:
Здравствуйте, McSeem2, Вы писали:

Бабло побеждает зло. Надо по ситуации использовать то, что дает максимальный профит.
Помните!!! ваш говнокод кому-то предстоит разгребать.
Re[15]: Не, программист - не инженер
От: vdimas Россия  
Дата: 14.12.10 22:14
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Я думаю это потому, что тем, кто выдает требования электронщикам, противоречивые требования просто не по карману. Иначе микроэлектронщики сталкивались с такими же требованиями так же часто. Из этого, по-моему, скорее можно сделать вывод о том, что микроэлектроника — более сложная отрасль. Но не обязательно.


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

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

В общем, обстановка поспокойнее.

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

Вот это и есть самое главное различие, остальное — ерунда.
Re[20]: Не, программист - не инженер
От: Кэр  
Дата: 15.12.10 17:08
Оценка:
Здравствуйте, FR, Вы писали:

FR>Мне все же интересно что ты там нового и потрясающего увидел, выше ты писал:


FR>

FR>Лично мне башню оторвало надолго серии, где показывали что такое на самом деле LINQ, что такое монады и как они тут рулят, как оно оборачивается в Rx, какие есть области применения. Я тут заобщался с Эриком Мейером (мега-дядька!) он утверждает и показывает, что Rx на самом деле решает проблему сложности параллельного программирования — я это хотел тут выложить и обсудить, просто руки еще не дошли.


FR>как руки дойдут, дай пожалуйста ссылку сюда.


Я уже ответил на этот вопрос:

Я здесь вижу главным то, что Rx это именно язык запросов поверх push based collections, которые являются дуальными к обычным pull based collections. Просто это получается чертовски удобно. И именно этого я не вижу в ваших примерах.

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


Если есть какие-то детали, которые мы могли бы обсудить предметно — welcome. Ссылки дать не могу, потому что мы это обсуждали с Эриком Мейером в личной беседе. Также надо понимать, что здесь я излагаю свое понимание, которое может отличаться от его личного мнения.

По общей теме Rx видео тут выкладывали неоднократно уже.
Re[21]: Не, программист - не инженер
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.12.10 02:33
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>По общей теме Rx видео тут выкладывали неоднократно уже.

Довольно интересно про Rx писал Барт.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Не, программист - не инженер
От: Кэр  
Дата: 16.12.10 14:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

Кэр>>По общей теме Rx видео тут выкладывали неоднократно уже.

S>Довольно интересно про Rx писал Барт.

Барт чувак грамотный бесспорно. Но вот про асинхронное программирование в целом — я там много мыслей не увидел (но и просмотрел я записи сейчас по диагонали и в сэмплы, которые он выкладывал, не заглядывал). Впрочем могу постараться спросить его во вторник, и мнением Эрика поинтересоваться заодно Тоха, у тебя есть какие-нибудь конкретные соображения, возражения на счет возможностей использования Rx в качестве главного движка параллельных вычислений?
Re[23]: Не, программист - не инженер
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.12.10 16:58
Оценка: 12 (3) +1
Здравствуйте, Кэр, Вы писали:


Кэр>Барт чувак грамотный бесспорно. Но вот про асинхронное программирование в целом — я там много мыслей не увидел (но и просмотрел я записи сейчас по диагонали и в сэмплы, которые он выкладывал, не заглядывал). Впрочем могу постараться спросить его во вторник, и мнением Эрика поинтересоваться заодно Тоха, у тебя есть какие-нибудь конкретные соображения, возражения на счет возможностей использования Rx в качестве главного движка параллельных вычислений?

Неа. Я ж теперь от этого далёк, как декабристы от народа. Мой инструмент нынче — PowerPoint, тудыть его в качель!

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

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

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

А про параллельность я пока ещё сам не вкурил, кто тут async и кого тут await. Вот, знаю классическую неразрешимую задачу: превратить pull stream в push stream. Простейший пример: есть web service, задача которого — принимать некий XML и как-то его внутри себя переваривать. XML большой, приезжает из сети, есссно, пакетами. Паузы между пакетами — бесконечно велики (с точки зрения CPU). Все классические парсеры XML — активны, "дайте мне поток, уж я из него повычитаю всё". Но это означает, что поток, рискнувший позвать парсер, не вернёт управление до окончания вычитывания. То есть, натравив его напрямую на сокет, мы получим красавицу, спящую большую часть времени.
Традиционное асинхронное решение — зачитать XML целиком в память, и только в конце позвать парсер. Оно мне не нравится:
1. Возрастают потребности в памяти. Я в течение очень долгого времени вынужден удерживать мегабайты в хипе. Реактивный парсер позволил бы мне на ходу избавляться от шлака, разбирая поток. (А, в перспективе, и сразу избавляться от более ненужных DOM-объектов, сразу скармливая себя в, скажем, XSLT)
2. Если мне передают мусор, я об этом не узнаю до окончания передачи. Реактивный парсер бы увидел ошибку, отправил 400 Bad Request и закрыл соединение сразу.

В общем-то, понятно, что вообще все традиционные парсеры построены в активном стиле. Написать реактивный парсер вручную — я, пожалуй, сразу и не возьмусь.
Умение автоматически превращать активный парсер в реактивный было бы очень круто. Rx как раз стоит где-то вокруг этого.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Не, программист - не инженер
От: Кэр  
Дата: 16.12.10 21:26
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Кэр, Вы писали:



Кэр>>Барт чувак грамотный бесспорно. Но вот про асинхронное программирование в целом — я там много мыслей не увидел (но и просмотрел я записи сейчас по диагонали и в сэмплы, которые он выкладывал, не заглядывал). Впрочем могу постараться спросить его во вторник, и мнением Эрика поинтересоваться заодно Тоха, у тебя есть какие-нибудь конкретные соображения, возражения на счет возможностей использования Rx в качестве главного движка параллельных вычислений?

S>Неа. Я ж теперь от этого далёк, как декабристы от народа. Мой инструмент нынче — PowerPoint, тудыть его в качель!

Тоже вещь полезная! Лишь бы не единственная

S>Rx меня в своё время поразил как адекватный ответ всем этим ужасным message pump-ам. В том смысле, что в пору моей юности постоянно бесило то, что безалаберные разработчики компонентов предлагали мало готовых евентов. А чтобы сконструировать свой банальный дабл-клик, нужно повеситься на несколько евентов сразу, да грамотно обработать всякие последовательности. Я, конечно, со временем понял, что всё сводится к построению конечного автомата, но один хрен логика оставалась размазана по чёрт-те-чему.


S>Rx для меня стал воплощением идеи лёгкого построения "композитных" событий и конечного автомата, который для них нужен.

S>Ну, то есть вместо того, чтобы проверять в MOUSE_UP "не записал ли я тут по соседству координаты и время предыдущего MOUSE_DOWN", я беру и описываю композит из двух евентов подряд, сравнивая их между собой. Вроде бы был такой как раз пример в ранних упоминаниях Rx. Должно быть, это поможет выпиливать всякие забавные кунштюки типа мышиных жестов.

Именно. Тот же drag&drop — это просто один запрос, который зипует последовательность координат движения мышкой после нажатия левой кнопки в последовательность перемещений, которые можно применить к какому-нибудь объекту. И подписавшись уже на последовательность перемещения объекта — получаем нативный drag&drop. К которому очень легко прикрутить эффекты типа "а вот когда мы еще плывем над этой областью — начни подсвечивать перетаскиваемый объект". Это просто дополнительный клауз для квери над событиями.

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


Для UI эта штука должна быть просто незаменима. Но это далеко не все, как мне сейчас кажется.

S>В общем-то, понятно, что вообще все традиционные парсеры построены в активном стиле. Написать реактивный парсер вручную — я, пожалуй, сразу и не возьмусь.

S>Умение автоматически превращать активный парсер в реактивный было бы очень круто. Rx как раз стоит где-то вокруг этого.

Автоматического превращения тут никто не обещает. Но новый код писать в таком стиле получается довольно просто — посмотри вот это видео, где он показывает вызов удаленного сервиса для dictionary lookup странички:
http://live.visitmix.com/MIX10/Sessions/FTL01

Плюс новый код интегрировать к старому получается очень легко (и это очень важно!) за счет того, что IEnumerable превратить в IObservable и обратно — очень легко и просто. Так что можно просто в какой-то момент продолжить писать продукт с помощью Rx запросов и обработчиков.
Re[24]: Не, программист - не инженер
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 18.12.10 08:46
Оценка: 110 (3)
Здравствуйте, Sinclair, Вы писали:

S>Умение автоматически превращать активный парсер в реактивный было бы очень круто. Rx как раз стоит где-то вокруг этого.


http://code.msdn.microsoft.com/RxParsers
Re[2]: Инструменты
От: McSeem2 США http://www.antigrain.com
Дата: 20.12.10 04:22
Оценка:
Здравствуйте, Visor2004, Вы писали:
V>Бабло побеждает зло. Надо по ситуации использовать то, что дает максимальный профит.

Не согласен. Надо использовать то, что дает максимальный кайф. Профит != кайф. Иногда бывают совпадения, что и профит и кайф, но редко.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[3]: Инструменты
От: Visor2004  
Дата: 20.12.10 20:24
Оценка:
Здравствуйте, McSeem2, Вы писали:

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

V>>Бабло побеждает зло. Надо по ситуации использовать то, что дает максимальный профит.

MS>Не согласен. Надо использовать то, что дает максимальный кайф. Профит != кайф. Иногда бывают совпадения, что и профит и кайф, но редко.


Это только если хобби совпадает с работой, и можно смириться с небольшими потерями в профите ради кайфа в реальной жизни так редко бывает, обычно только в начале карьеры.
Помните!!! ваш говнокод кому-то предстоит разгребать.
Re[4]: Инструменты
От: McSeem2 США http://www.antigrain.com
Дата: 24.12.10 18:04
Оценка:
Здравствуйте, Visor2004, Вы писали:

V>Это только если хобби совпадает с работой, и можно смириться с небольшими потерями в профите ради кайфа в реальной жизни так редко бывает, обычно только в начале карьеры.


Отсюда вывод — надо менять карьеру и все время оставаться в состоянии "в начале карьеры".
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[20]: Не, программист - не инженер
От: Трурль  
Дата: 27.12.10 06:58
Оценка: :)
Здравствуйте, FR, Вы писали:


FR>Когда нужно программисты тоже понимают цену ошибок и разрабатывают с минимизацией ошибок, вот только строка такого кода стоит

FR>на порядок дороже и строк этих (учитывая тесты и переписывание) приходится писать намного больше.

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

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

 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.