Re[3]: С vs C++ - Компьютерные священные войны

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

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

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

I>>>нет хорошо доступных серьезных инструметов например
I>>>1 для рефакторинга,
I>>>2 отладки
I>>>3 анализа кода

M>>Это ты зря сказал

M>>Сейчас тебя загрызать будут

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

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

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

-- это все от того что программист не уверен в том что пишет... а не уверен в основном от того что не думает, или думает слишком узко ... (мое такое имхо)

второе это просмотр коры... собственно в 90% случаев именно для этого я использую GDB -- какиета мега IDE и прочий гуйный хлам нафиг тут не сдался...

`gdb mybinary core`
bt

вот и все!
зачем вокруг нескольких команд (fr, thr, bt, p, x) делать front endы для меня загадка...

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

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

со средствами рефакторинга как известно есть проблемы -- не раз обсуждалось почему и от чего это так (и в данном контексте оффтопик)...
опять таки скажу с позиции лично моего опыта: ну да несколько не удобно работать, но не архисложно... т.е. даже "не сложно"... ибо большая часть рефакторингов делается руками в редакторе... ну да вместо "одной кнопочки" (точнее меню, диалога, и нажатия Ок) приходится копипакостничать, пользоваться find/replace + regex. А также выручает умение моего редактора пропайпить выделенный текст через любой фильтр (сымсле конвейер, если кто не понял) -- и вот тут всякие IDE с решарперами могут покурить в сторонке... в более сложных случаях на помощь приходят find, grep, sed, xargs, & etc выполняемые из консоли... но это все мелочи по сравнени с тем что сначало приходтся фтыкать в говнокод, потом думать как это улучшить малой кровью и только после этого начать чегото колбасить... вот это я назвал бы полным циклом рефакторинга, а не только последнюю часть связанную с редактированием текста ... дык вот во всем этом цикле сэкономленное время мне кажется не мегасущественным... -- на обед времени тратицо гараздо больше

про отладку уже сказал выше

анализ кода? это о чем? смысле поиск багов без компиляции? навигация по коду? -- не зная что аффтар имел ввиду просто перечислю чем я еще пользуюсь в работе:
ctags -- ну какая-никакая навигация (прикручен в редактор)
lint -- статический анализатор кода... крайне редко пользовался (фактически пару раз когда захотелось проаналайзить откровенно аццкий быдлокод стереть который немедленно было нельзя)... в природе есть еще там какиета подобные тулзы -- но это все для реальных проектов не канает... ошибки обычно более сложные чем они могут находить (если конечно код писали не студенты практиканты)
valgrind -- отдельного представления не требуется я думаю...
strace,truss & etc -- ну тоже все понятно...

все инструменты "хорошо доступны" и крайне серьезные

-- не прочитав ман фиг попользуешься в полный рост чтобы

AZ>Не плохо и не хорошо это, просто по другому.
+100500

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

AZ>>Вот возникает вопрос почему так, когда с++ современее, удобнее. Есть библиотеки типа boost, stl.
I>Есть в с++ нечто, что рождает монстров вроде буста и стл, и благодаря им так и сложилось с серверами.

На самом деле ни буст ни стл не являются необходимым условием написания программ, даже таких хитрых, как промышленный веб-сервер. Ни что не мешает с нуля сделать свои библиотеки с преферансом и гетерами — так как это обычно делают на голом С, типичный пример apache и его apr + apr-util.

AZ>>Какие могут быть обьяснения тому?
AZ>>У меня такие:
AZ>>Почему пишут на с:
AZ>>1. в отладчике gdb приятнее видеть короткий простой код на с

на самом деле gdb довольно хорошо умеет работать и с с++.

AZ>>2. не знают с++, поэтому пишут на с

Возможно. Но тогда скорее всего пишут на "си с классами".

AZ>>3. переносимость под другие платформы, все же мне кажется код на с переносимее чем на с++

Ну, если учесть, что компилятор, который нормально умеет компилировать под разные платформы всего один, и он один и тот же для c и c++

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

AZ>>4. нет инструментов типа, таких как под винду, для рефакторинга и прочее, с инструментами типа gdb, emacs, vim п омоеум сложнее писать на с++

Имхо никакой разницы нет — поддержка этих языков практически одинакова.

I>нет хорошо доступных серьезных инструметов например
I>1 для рефакторинга,
I>2 отладки
I>3 анализа кода

Опять-таки ситуация с С и С++ в этом плане практически одинакова. И она не является препятствием для написания серверов

I>компиляторы между собой слабовато совместимы, собственно это и показывает ущербность языка

И опять-таки это не важно для выбора C vs C++

Здравствуйте, abdul.zycor, Вы писали:
AZ>Написав код в студии я сразу же пытаюсь его отлаживать, протрейсить его весь или частично

Да ну, бросай ты это дело. Если время есть — лучше и правда тест написать — на будущее останется.

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

IID>>Тем не менее это не мешает "мясо" библиотеки писать на С++, а наружу выставлять pure-С API. Вон, в винде дофига юзерленда именно так сделано.
V>Ну это кривизна необыкновенная. Когда два С++ класса общаются между собой на C, и лишены возможностей взимодействовать с использованием возможностей С++. И то, как это сделано в ВинАПИ, кстати, есть тоже кривулина.

Всё дело в волшебных пузы^W^W правильной декомпозиции. Зато "внутренности" православно написаны на плюсах. К тому же задействование возможностей С++ во внешних интерфейсах автоматически кладёт болт на другие языки. Т.к. биндинги к pure-С есть у всех, а с С++ это не так.

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

_>>Для этого extern C есть.
V>Особенно он полезен, когда в библиотеку помещаются классы.
Этот аргумент невероятно полезен при сравнении С++ и С. Или при использовании С ты сможешь экспортировать классы?

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

AZ>Всем привет! Не так давно стал изучать программирование для unix систем.
AZ>Возникло впечетление, что большая часть кода всяких серверов написана на с, а не на с++.
AZ>Вот возникает вопрос почему так, когда с++ современее, удобнее. Есть библиотеки типа boost, stl.
AZ>Какие могут быть обьяснения тому?
AZ>У меня такие:
AZ>Почему пишут на с:
AZ>1. в отладчике gdb приятнее видеть короткий простой код на с
AZ>2. не знают с++, поэтому пишут на с
AZ>3. переносимость под другие платформы, все же мне кажется код на с переносимее чем на с++
AZ>4. нет инструментов типа, таких как под винду, для рефакторинга и прочее, с инструментами типа gdb, emacs, vim п омоеум сложнее писать на с++
AZ>5. мног окода написано уже на с, хоят и новые почему-то пишут на с

AZ>В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста

.
C++ позволяет сильно автоматизировать и упрощать многие вещи (та же работа со строками или STL). Это не означает, что на C++ нельзя написать код, идентичный по производительности коду на C и при этом занимающий в 2 раза меньше строк. Но означает, что для того, чтобы написать громоздкое приложение на C надо писать много кода, на C++ для этого достаточно пару раз не задуматься о последствиях и поюзать стандартные конструкции кривым способом.
Например, хэш-таблицу для повторяющихся строк на C можно реализовать, вручную распихав строки в едином блоке без дублирования совпадающих подстрок и сделав вычисление хэшей. Займет это N строк. На C++ все можно реализовать аналогично низкоуровнево, займет это меньше N строк и будет иметь красивую модульную структуру. НО всегда найдется программист, который поюзает std::map<std::string, std::string>, не вьезжая в принцип его работы, чем увеличит требуемый размер памяти в разы.
На практике получается, что объяснить программистам, как писать компактный и производительный код на С++ сложнее, чем запретить им пользоваться чем-либо кроме C. Увы.

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

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

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

Думаю в тут можно заменить "быдлокодера" на "быдлолетчика" ))

... << RSDN@Home 1.2.0 alpha 4 rev. 1410>>

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

A>Думаю в тут можно заменить "быдлокодера" на "быдлолетчика" ))

"Быдлокодер" за штурвалом с большей вероятностью все и всех похерит )))

... << RSDN@Home 1.2.0 alpha 4 rev. 1410>>

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

PD>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.

I>Это как бы ЯВУ, на самом дело недо-ЯВУ.

Совместимость с C делает его недо-ЯВУ.
Если из него убрать все эти недо-ЯВУ, то будет Java или C#.
Одна из таких попыток — это Managed C++ Микрософта.

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

PD>>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.

I>>Это как бы ЯВУ, на самом дело недо-ЯВУ.

ТС>Совместимость с C делает его недо-ЯВУ.

Objective-C тоже совместим с С, но при этом он настоящий ЯВУ.

ТС>Если из него убрать все эти недо-ЯВУ, то будет Java или C#.

Совсем не обязательно.

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

AZ>Написав код в студии я сразу же пытаюсь его отлаживать, протрейсить его весь или частично

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

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

AZ>Какие могут быть обьяснения тому?

http://www.kernel.org/pub/linux/docs/lkml/#s15-3

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

I>Objective-C тоже совместим с С, но при этом он настоящий ЯВУ.

Вы еще дрочите на мак? Тогда мы идем к Вам. Ты на нем хоть что нибудь писал, интересно?

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

KV>С++ — это ЯВУ, согласен. Жаль только, что уже давно появились мега-ЯВУ, гипер-ЯВУ, супер-ЯВУ и, конечно же, пупер-ЯВУ. Со всеми вытекающими...

На которых пишут не программисты (как на С++), а всякие супер- и пупер-программисты

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

BB>Здравствуйте, abdul.zycor, Вы писали:

AZ>>Какие могут быть обьяснения тому?

BB>http://www.kernel.org/pub/linux/docs/lkml/#s15-3
[quote]There is no point in just compiling the kernel with g++ and writing the odd function in C++, this would just result in a confusing mix of C and C++ code. Either the kernel is left in C, or it's all moved to C++.[/quote]
Ну это просто зашибись аргумент. Типа, или всё бросить и начать сначала, или ничего не трогать и закрыть глаза на удобные фичи C++. Ну типа нах нам автоматическая коробка, ведь это надо все машины с ручной в утиль сдать, а потом выпускать на улицы автомат. А то чтобы по одной улице одни ездили на "ручке", а другие на "автомате" — это же некошерно. Да и Торвальдс не разрешит.
О том, как бы поюзать часть удобных фич C++, дабы быстрее и качественнее решить проблемы, стоящие перед разработчиками сейчас, никто и не задумывается. Элементарно можно создать inline wrapper-ы на С++ вокруг существующего API на C — вызывать будет удобнее (те же mutex guard-ы можно красиво реализовать), размер бинаря не увеличит, ибо все разрезолвится во время компиляции. Ту же VFS сделать на базе виртуальных функций, чтобы унаследовал класс, переопределил 3 метода, вернул new MyClass(); из entry point — и VFS юзабельна. Но ведь нет — куда кошернее руками заполнять таблицы указателей и кастить inode->extension к struct my_vfs_driver_extension в каждом вызове...

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

ТС>Одна из таких попыток — это Managed C++ Микрософта.
Надо сказать, получилось говно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

M>Это ты зря сказал

M>Сейчас тебя загрызать будут

Учитывая его репутацию скорее проигнорируют.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>Дело в том, что С по всем признакам есть платформа, хотя это всего лишь язык.

Само собой, на нём ведь API всех популярных ОС написано.

Думаю на BeOS ощущения несколько иные

.

I>Язык С++ хотя и мощнее С, но всего лишь язык и на платфому ну никак не тянет.

Почему? С — это подмножество. Вообще все забывают о том, что одна из основополагающих фишек С++ — ты не платишь за то, чем не пользуешься. Ну так и классами и stl-ем никто пользоваться не заставляет, а вот перегрузка функций и шаблоны могут очень сократить количество кода, не отразившись негативно на производительности. Т.е. С++ чувствует себя на платформе С, не хуже, а даже и лучше, чем F# на платформе .Net.

I>Я такую вещь заметил, что чем больше пишу на С#, тем
I>1 труднее переключаться на С++
I>2 легче писать на Си.
Что как бе намекает нам о снижении уровня... абстракции?

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

I>>Язык С++ хотя и мощнее С, но всего лишь язык и на платфому ну никак не тянет.

DC>Почему? С — это подмножество. Вообще все забывают о том, что одна из основополагающих фишек С++ — ты не платишь за то, чем не пользуешься.

между компилерами с++ совместимость крайне слабая, все они совместимы на уровне Си

I>>Я такую вещь заметил, что чем больше пишу на С#, тем
I>>1 труднее переключаться на С++
I>>2 легче писать на Си.
DC>Что как бе намекает нам о снижении уровня... абстракции?

нет, дело не в уровне абстракции. в си все что надо вызывается явно. В С++ злоупотребили неявным вызовом функционала, при том что эти неявные вызовы все равно приходится контролировать.
Т.е. в С++ снижения уровня абстракции по факту нет.
В C# нет таких проблем как в с++.

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

I>между компилерами с++ совместимость крайне слабая, все они совместимы на уровне Си

Не правда, я каждый день собираю код xlc 10 и ms vc 2005, совместимость отличная, есть конечно тонкости но они в основном связаны с линковкой, а у AIX-а и Винды они очень разные.

I>>>Я такую вещь заметил, что чем больше пишу на С#, тем
I>>>1 труднее переключаться на С++
I>>>2 легче писать на Си.
DC>>Что как бе намекает нам о снижении уровня... абстракции?

I>нет, дело не в уровне абстракции. в си все что надо вызывается явно. В С++ злоупотребили неявным вызовом функционала, при том что эти неявные вызовы все равно приходится контролировать.
I>Т.е. в С++ снижения уровня абстракции по факту нет.
I>В C# нет таких проблем как в с++.

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

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

DC>Не правда, я каждый день собираю код xlc 10 и ms vc 2005, совместимость отличная, есть конечно тонкости но они в основном связаны с линковкой, а у AIX-а и Винды они очень разные.

А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.

I>>нет, дело не в уровне абстракции. в си все что надо вызывается явно. В С++ злоупотребили неявным вызовом функционала, при том что эти неявные вызовы все равно приходится контролировать.
I>>Т.е. в С++ снижения уровня абстракции по факту нет.
I>>В C# нет таких проблем как в с++.

DC>В С нужно писать тонны boilplate кода, это его основная проблема, а вот С++ позволяет сократить количество кода, но никто тебя не заставляет использовать конструкции несущие неявную семантику.

Я и не использую, потому языком С++ это крайне сложно назвать.

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

I>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.

У нас их крайне мало.

Несмотря на то, что сначала это были xlc 5 и VC98.

I>Я и не использую, потому языком С++ это крайне сложно назвать.

Ты в эту ветку о C# пришёл пописать?

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

I>>>Язык С++ хотя и мощнее С, но всего лишь язык и на платфому ну никак не тянет.
DC>>Почему? С — это подмножество. Вообще все забывают о том, что одна из основополагающих фишек С++ — ты не платишь за то, чем не пользуешься.
I>между компилерами с++ совместимость крайне слабая, все они совместимы на уровне Си
Это в общем случае.
ICC например совместим с MSVC и GCC (линуховая версия ICC).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dr.Chaos, Вы писали:
DC>В С нужно писать тонны boilplate кода, это его основная проблема, а вот С++ позволяет сократить количество кода, но никто тебя не заставляет использовать конструкции несущие неявную семантику.
В соседней ветке, кстати, обсуждается возможность улучшить C не путем превращения его в C++, а путем улучшения макросов.

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

I>>>>Язык С++ хотя и мощнее С, но всего лишь язык и на платфому ну никак не тянет.
DC>>>Почему? С — это подмножество. Вообще все забывают о том, что одна из основополагающих фишек С++ — ты не платишь за то, чем не пользуешься.
I>>между компилерами с++ совместимость крайне слабая, все они совместимы на уровне Си
CC>Это в общем случае.
CC>ICC например совместим с MSVC и GCC (линуховая версия ICC).

ICC это экзотика.

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

CC>>ICC например совместим с MSVC и GCC (линуховая версия ICC).
I>ICC это экзотика.
Вау! А пацаны то и не знают.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.

DC>У нас их крайне мало.

Несмотря на то, что сначала это были xlc 5 и VC98.

А я не про ваш код говорю, а про тот, который мне довелось видеть.

I>>Я и не использую, потому языком С++ это крайне сложно назвать.

DC>Ты в эту ветку о C# пришёл пописать?

Я вообще то про С говорю. Про C# было в контексте Си

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

I>>>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.
DC>>У нас их крайне мало.

Несмотря на то, что сначала это были xlc 5 и VC98.
I>А я не про ваш код говорю, а про тот, который мне довелось видеть.
Ну дык не смотри больше на хреновый код.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>>>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.
DC>>>У нас их крайне мало.

Несмотря на то, что сначала это были xlc 5 и VC98.
I>>А я не про ваш код говорю, а про тот, который мне довелось видеть.
CC>Ну дык не смотри больше на хреновый код.

Какой пишут на такой и смотрю. При чем пишут люди, которые во всю ругают индусокод. Так шта...

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

PD>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ...

недоЯВУ. Со всеми вытекающими.

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

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

I>>>>>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.
DC>>>>У нас их крайне мало.

Несмотря на то, что сначала это были xlc 5 и VC98.
I>>>А я не про ваш код говорю, а про тот, который мне довелось видеть.
CC>>Ну дык не смотри больше на хреновый код.

I>Какой пишут на такой и смотрю. При чем пишут люди, которые во всю ругают индусокод. Так шта...
это что у нас теперьь новое мерило для "проффесианализма"??? начал ругать индусокод, значит мега профессионал?

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

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

I>При чем пишут люди, которые во всю ругают индусокод.
Честно говоря мне не известны люди, которые бы хвалили индусокод.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>Здравствуйте, труженик села, Вы писали:

PD>>>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.
I>>>Это как бы ЯВУ, на самом дело недо-ЯВУ.
ТС>>Совместимость с C делает его недо-ЯВУ.
Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет? Код более читабелен, по сравнению с альтернативами? Производительность не меньше? Какие тогда проблемы юзать язык в тех задачах, где от него есть польза, забив, труъ ли это ЯВУ? Или надо шашечки, а не ехать?

I>Objective-C тоже совместим с С, но при этом он настоящий ЯВУ.
Там синтаксис невменяемый.

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

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

I>>При чем пишут люди, которые во всю ругают индусокод.
CC>Честно говоря мне не известны люди, которые бы хвалили индусокод.

А как же сами индусы?

... << RSDN@Home 1.2.0 alpha 4 rev. 1421>>

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

I>>Какой пишут на такой и смотрю. При чем пишут люди, которые во всю ругают индусокод. Так шта...
Z>это что у нас теперьь новое мерило для "проффесианализма"??? начал ругать индусокод, значит мега профессионал?

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

Дай объявление в местную газету, что бы не ругали, а исправляли и сами такой не писали.

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

PD>>>>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.
I>>>>Это как бы ЯВУ, на самом дело недо-ЯВУ.
ТС>>>Совместимость с C делает его недо-ЯВУ.
B>Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет? Код более читабелен, по сравнению с альтернативами? Производительность не меньше? Какие тогда проблемы юзать язык в тех задачах, где от него есть польза, забив, труъ ли это ЯВУ? Или надо шашечки, а не ехать?
Это КСВ, тут принято кидать какашками в друг дружку. Причем всем ведь (кроме закостенелых троллей) на самом деле глубоко накакать на результат флейма. На практике все вменяемые люди будут применять тот либо иной язык исходя из практических соображений, а не от написанного/прочитанного тут.

I>>Objective-C тоже совместим с С, но при этом он настоящий ЯВУ.
B>Там синтаксис невменяемый.
Ну вот, так хорошо начал, а сам?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>>При чем пишут люди, которые во всю ругают индусокод.
CC>>Честно говоря мне не известны люди, которые бы хвалили индусокод.

A>А как же сами индусы?

Индусы или индусокодеры? Ты уточни кого ты имеешь в виду.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

A>>А как же сами индусы?

CC>Индусы или индусокодеры? Ты уточни кого ты имеешь в виду.

Индусокодеры

... << RSDN@Home 1.2.0 alpha 4 rev. 1421>>

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

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

A>>>А как же сами индусы?

CC>>Индусы или индусокодеры? Ты уточни кого ты имеешь в виду.

A>Индусокодеры

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>ICC например совместим с MSVC и GCC (линуховая версия ICC).

Кстати, xlc с 9й версии (а может и раньше) совместим с gcc на уровне ключей.

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

MC>В соседней ветке, кстати, обсуждается возможность улучшить C не путем превращения его в C++, а путем улучшения макросов.

С с такими макросами — уже не С будет

. Т.е. если туда добавить гигиенические макры и в совокупности с llvm мы лисп порвём на тряпки

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

Мне в этом плане намного симпатичней Go, но получится ли его сделать столь же производительным?

Здравствуйте, dr.Chaos, Вы писали:
DC>мы лисп порвём на тряпки

, по гибкости и скорости.
Или превратимся в лисп.

DC>Но есть у меня сомнения что гигиенические макры дадуться бесплатно.
Я слышал, что строгая типизация вносит сложности в макросы. Т.е., видимо, придется дополнительно черпать идеи из nemerle/haskell/...
Еще для гигиены желательно наличие какого-то механизма пространств имен, чтобы развернутый в разных местах программы макрос ссылался на одни и те же функции/макросы (которые были видны в месте его определения).

DC>Мне в этом плане намного симпатичней Go, но получится ли его сделать столь же производительным?
Кстати, а откуда исходит уверенность в том, что go будет супершустрый, как C? Там же, я так понял, планируется применять такие высокоуровневые вещи, как процессы/каналы, интерфейсы с аналогом утиной типизации и т.п. Т.е. мне показалось, это будет что-то типа эрланга, что-ли.

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

MC>Или превратимся в лисп.

Только быстрый и типизированный.

DC>>Мне в этом плане намного симпатичней Go, но получится ли его сделать столь же производительным?
MC>Кстати, а откуда исходит уверенность в том, что go будет супершустрый, как C? Там же, я так понял, планируется применять такие высокоуровневые вещи, как процессы/каналы, интерфейсы с аналогом утиной типизации и т.п. Т.е. мне показалось, это будет что-то типа эрланга, что-ли.

В супершустрости Go я не уверен, но мне нравится как в нём решены многие проблемы, пока нравится. А процессы/каналы я и в С использовать могу, это не делает его дальше от железа.

Я, вообше, к тому говорил, что С не заменит язык с макросами, а заменит лишь язык с простым и мощным набором фич. Хотя может его ничего и не заменит в обозримом будущем.

Здравствуйте, dr.Chaos, Вы писали:
DC> но мне нравится как в нём решены многие проблемы
Имеются в виду проблемы C? А можно в двух словах? Я просто с этой стороны на Go не смотрел. Вроде как с хедерами разобрались раз и навсегда. Наверняка с контролем за размерами буферов и т.п. получше. А вот как там с обработкой ошибок/освобождением ресурсов? Эксепшены?

DC>А процессы/каналы я и в С использовать могу, это не делает его дальше от железа.
Я так понял во Go процессы "юзерспейсные", а не потоки ОС. Т.е. вроде как в порядке вещей наплодить их много-много (ну я судил по примеру с prime sieve). Плюс вроде там сборка мусора есть. Хотя вон, предшественник (как я понял) go — limbo — использовался как раз для системного программирования в inferno.

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

MC>Имеются в виду проблемы C? А можно в двух словах? Я просто с этой стороны на Go не смотрел. Вроде как с хедерами разобрались раз и навсегда. Наверняка с контролем за размерами буферов и т.п. получше.

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

MC>А вот как там с обработкой ошибок/освобождением ресурсов? Эксепшены?

Там с обработкой ошибок ещё не решили до конца, пока коды возврата. Думаю при желании можно накрутить сверху монаду Maibe

.

MC>Я так понял во Go процессы "юзерспейсные", а не потоки ОС. Т.е. вроде как в порядке вещей наплодить их много-много (ну я судил по примеру с prime sieve). Плюс вроде там сборка мусора есть. Хотя вон, предшественник (как я понял) go — limbo — использовался как раз для системного программирования в inferno.

Goroutines мапятся на реальные нити, но как — хз, только рантайм знает

. Не думаю что сборка мусора будет большой проблемой.

Здравствуйте, dr.Chaos, Вы писали:
DC>Goroutines мапятся на реальные нити, но как — хз, только рантайм знает

. Не думаю что сборка мусора будет большой проблемой.
Мне почему-то казалось, что С используют те, кто "не любит", когда рантайм делает за кадром слишком многое: создает потоки, управляет памятью и т.п. (потому и немного странно было, когда в Go сравнивался с С). Это не так?

Мне нравится простота языка, но между "мне нравится" и "замена С" сам понимаешь пропасть, я, собственно, и не берусь утверждать что Go заменит C (да и не верю в это), просто ИМХО у подхода с небольшим набором фич больше шансов.

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

MC>Мне почему-то казалось, что С используют те, кто "не любит", когда рантайм делает за кадром слишком многое: создает потоки, управляет памятью и т.п. (потому и немного странно было, когда в Go сравнивался с С). Это не так?

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

А то в с++ приходится явно контролировать неявное

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

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

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

B>На практике получается, что объяснить программистам, как писать компактный и производительный код на С++ сложнее, чем запретить им пользоваться чем-либо кроме C. Увы.

Казалось бы, запретить вообще stl нафиг и разарботать своё, безопасное...

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

DC>В С нужно писать тонны boilplate кода, это его основная проблема, а вот С++ позволяет сократить количество кода, но никто тебя не заставляет использовать конструкции несущие неявную семантику.

Мало того, можно довольно легко родить анализатор, который укажет на "некашерные" места...

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

I>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.
Дык ты С-шные исходники под много компиляторов видел?

E>Казалось бы, запретить вообще stl нафиг и разарботать своё, безопасное...

Чем тебе STL-то не угодил? Где в нем опасность?

E>Можно было бы на платформе застандартизировать принцип декорирования имён.
Можно было бы. Манилова помнишь?

E>Можно через виртуальные функции и интерфейсы всё делать на худой конец...

А эти тут причем?

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

V>Чем тебе STL-то не угодил? Где в нем опасность?
Очень легко написать очень неэффективный код. Предполагает очень умного и знающего пограммиста.
Собственно я отвечал на сообщение, где наличие STL упоминадось как недостаток С++.
Можно разработать менее кудрявый фреймворк, который будет не таким легко расширяемым и универсальным, но, зато, и не будет провоцировать написание неэффективного кода по незнанию...

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

V>Можно было бы. Манилова помнишь?
При чём тут Манилов? В чём проблема вообще сделать декорирование настраиваемым в любом компиляторе?
Вот была бы часть API линукса на С++ и все бы как миленькие декарировали бы имена так же, как и gcc...

Другое дело, что взаимодействие с другими языками было бы *сильно затруднено*, ну да и фиг бы с ним, с другой стороны...

E>>Можно через виртуальные функции и интерфейсы всё делать на худой конец...

V>А эти тут причем?

Ну COM под виндой, например, знаешь?

E>При чём тут Манилов?
При том, что тот тоже мечтал о несбыточном.

E>В чём проблема вообще сделать декорирование настраиваемым в любом компиляторе?
Декорирование имен не входит в стандарт. Хорошо это или плохо — я не знаю. Наверное, плохо, но по-другому не выходит, потому что стандарт такими вещами не занимается.

E>Вот была бы часть API линукса на С++ и все бы как миленькие декарировали бы имена так же, как и gcc...
E>Другое дело, что взаимодействие с другими языками было бы *сильно затруднено*, ну да и фиг бы с ним, с другой стороны...
Во-во. Как бы ты взаимодействовал с этим кодом из С? Который декорировать не умеет никак?

E>Ну COM под виндой, например, знаешь?

КОМ к С++ никакого отношения не имеет. Так же как и к виртуальным функциям.

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

V>При том, что тот тоже мечтал о несбыточном.
Если ты не понял, то при чём тут несбыточное?

V>Декорирование имен не входит в стандарт. Хорошо это или плохо — я не знаю. Наверное, плохо, но по-другому не выходит, потому что стандарт такими вещами не занимается.
Да и пусть себе не входит. Вот если в Линуксе появится С++ API, в котором будет заданы правила декорирования, то все компиляторы под линукс легко смогут приделать опцию "придерживаться этих правил"...

V>Во-во. Как бы ты взаимодействовал с этим кодом из С? Который декорировать не умеет никак?
Через переходники.
Вот, например, к акве-какаве в МэкОС Х тоже никак, кроме как через ОбжективС не достучишься. И ничего, живут себе люди...
К .net тоже без управляемых заморок не подлезешь, а ничего, зовут, если надо и из неуправляемого кода...
GDI+, опять же...

E>>Ну COM под виндой, например, знаешь?

V>КОМ к С++ никакого отношения не имеет. Так же как и к виртуальным функциям.
Ну вот COM под виндой -- это пример того, как взяли в системе, да и стандаритизировали, фактически, то, как таблица виртуальных функций должна выглядеть. И ничего, всё у них получилось. Все компиллеры С++ под винду это дело поддержали...

А ведь декорирование имён -- это намного менее чувствительное место в компиляторе, чем реализация виртуальности...

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

E>Да и пусть себе не входит. Вот если в Линуксе появится С++ API, в котором будет заданы правила декорирования, то все компиляторы под линукс легко смогут приделать опцию "придерживаться этих правил"...

Стандарт де-факто — это gcc. Он достаточно backward compatible и его эмулирует icc.

Более того, он даже кодифицирован: http://www.codesourcery.com/public/cxx-abi/abi.html#mangling

E>Ну вот COM под виндой -- это пример того, как взяли в системе, да и стандаритизировали, фактически, то, как таблица виртуальных функций должна выглядеть. И ничего, всё у них получилось. Все компиллеры С++ под винду это дело поддержали...
Есть стандартизованный D-BUS. Прямой аналог COM, в общем.

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

V>КОМ к С++ никакого отношения не имеет. Так же как и к виртуальным функциям.

Странно.
А я как раз, было дело, руками лепил COM-интерфейс на C++.
И представлял он из себя ничто иное как C++ класс, у которого все методы — виртуальные.

Ну, как здесь, примерно, излагается:

It is no coincidence that the Win32 COM object layout matches closely the C++ object layout
The Win32 COM calling convention specifies the layout of the virtual method table (vtable) of an object

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

C>Стандарт де-факто — это gcc. Он достаточно backward compatible и его эмулирует icc.
C>Более того, он даже кодифицирован: http://www.codesourcery.com/public/cxx-abi/abi.html#mangling

Так я про то же! Проблема с манглином -- надуманная!
C>Есть стандартизованный D-BUS. Прямой аналог COM, в общем.
Угу

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

E>>Ну вот COM под виндой -- это пример того, как взяли в системе, да и стандаритизировали, фактически, то, как таблица виртуальных функций должна выглядеть. И ничего, всё у них получилось. Все компиллеры С++ под винду это дело поддержали...
C>Есть стандартизованный D-BUS. Прямой аналог COM, в общем.

Ога, а ты COM то видел ? Сравни и не пори чушь

COM

BOOL b;
BSTR bstr;

HRESULT hr = pSomePtr->GetStuff(&b,&bstr);

if(SUCCEEDED(hr))
{
 ...
}

D-BUS

gboolean boolret;
  char *strret;
  
  error = NULL;
  if (!dbus_g_proxy_call (proxy, "GetStuff", &error,
              G_TYPE_INVALID,
                          G_TYPE_BOOLEAN, &boolret,
                          G_TYPE_STRING, &strret,
              G_TYPE_INVALID))
    {
      /* Handle error */
    }
  printf ("%s %s", boolret ? "TRUE" : "FALSE", strret);
  g_free (strret);

D-Bus это докомовский период

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

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

I>>Здравствуйте, труженик села, Вы писали:

PD>>>>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.
I>>>>Это как бы ЯВУ, на самом дело недо-ЯВУ.
ТС>>>Совместимость с C делает его недо-ЯВУ.
B>Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет?

Позволяет. Но некоторые языки позволяют делать это лучше.

B>Код более читабелен, по сравнению с альтернативами?

Код читабелен? Бу-га-га

На С++ код конечно читабелен. По сравнению с Брейнфаком. Но не более.

B>Производительность не меньше? Какие тогда проблемы юзать язык в тех задачах, где от него есть польза, забив, труъ ли это ЯВУ? Или надо шашечки, а не ехать?

Ехать. Но с комфортом.

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

PD>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>С++ — это ЯВУ, согласен. Жаль только, что уже давно появились мега-ЯВУ, гипер-ЯВУ, супер-ЯВУ и, конечно же, пупер-ЯВУ. Со всеми вытекающими...

PD>На которых пишут не программисты (как на С++), а всякие супер- и пупер-программисты

Ага, я был программистом, а потом левел ап и я стал супер-программистом

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

I>Ога, а ты COM то видел ? Сравни и не пори чушь
1) Ты бы уж тогда всё на С писал...

I>COM

I>

I>BOOL b;
I>BSTR bstr;

I>HRESULT hr = pSomePtr->GetStuff(&b,&bstr);

I>if(SUCCEEDED(hr))
I>{
I> ...
I>}
I>

Но вернёмся к нашему С++
Вот этот вот самый COM'овский вызов pSomePtr->GetStuff и эксплуатирует совместимость формата виртуальных таблиц между разными средами разработки

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

E>Вот, например, к акве-какаве в МэкОС Х тоже никак, кроме как через ОбжективС не достучишься.

Если я правильно помню, все же можно — вроде, там есть некая библиотека, позволяющая C-коду взаимодействовать с Objective-C объектами.

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

B>>Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет?

___>Позволяет. Но некоторые языки позволяют делать это лучше.

Например?

Практики буквально на днях выясняли, что С++ таки самый лучший

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

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

B>>>Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет?

___>>Позволяет. Но некоторые языки позволяют делать это лучше.

NBN>Например?

Практики буквально на днях выясняли, что С++ таки самый лучший

Пруфлинк. Или нотариально заверенные скриншоты.

Примеров масса: С#, Nemerle, Lisp и многое. Если заведут старую пластинку про какой-нибудь драйвер, то уж лучше С.

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

I>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.

KV>>С++ — это ЯВУ, согласен. Жаль только, что уже давно появились мега-ЯВУ, гипер-ЯВУ, супер-ЯВУ и, конечно же, пупер-ЯВУ. Со всеми вытекающими...

I>Какой же он ЯВУ если в нем нет абстрагирования от вопросов связаных например с памятью а многие инструменты просто не работают ?
как-бы некоторый уровень абстрагирования есть. Если не изобретать ядерного реактора, то с распределением памяти не сталкиваешься.
А про инструменты: таки, может, дело в инструментописателях?

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

I>Здравствуйте, dr.Chaos, Вы писали:

I>>>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.

DC>>У нас их крайне мало.

Несмотря на то, что сначала это были xlc 5 и VC98.

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

ты давно иномарки ругал за то, что ими управляют водятлы?

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

DC>>>У нас их крайне мало.

Несмотря на то, что сначала это были xlc 5 и VC98.

I>>А я не про ваш код говорю, а про тот, который мне довелось видеть.
M_>неплохая причина ругать язык

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

Это только один из примеров.

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

I>>Какой же он ЯВУ если в нем нет абстрагирования от вопросов связаных например с памятью а многие инструменты просто не работают ?
M_>как-бы некоторый уровень абстрагирования есть. Если не изобретать ядерного реактора, то с распределением памяти не сталкиваешься.

Для начала надо на раз выучить и использовать RAII. Сам язык дает слишком большой простор.

отсюда неудивительно наблюдать винигрет недо-библотек и мега-монстров

M_>А про инструменты: таки, может, дело в инструментописателях?

Один ты умный, да.

Парсить С++ код та еще задача. до сих пор нет нормального средства рефакторинга, которое было бы таким же доступным как и то что есть в решарпере.

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

В C# например пошли именно этим путем — облегчили работу людям которые пишут средства разработки.

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

I>>Ога, а ты COM то видел ? Сравни и не пори чушь
E>1) Ты бы уж тогда всё на С писал...

Вот тебе COM на C

HRESULT hr = pSomePtr->GetStuff(pSomePtr->lpVtbl,&b,&bstr);

всего то this явно передаешь. Можешь хоть COM сервер на C писать, никаких проблем.

E>Но вернёмся к нашему С++
E>Вот этот вот самый COM'овский вызов pSomePtr->GetStuff и эксплуатирует совместимость формата виртуальных таблиц между разными средами разработки

не между средами, а между компиляторами.

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

DC>>>>У нас их крайне мало.

Несмотря на то, что сначала это были xlc 5 и VC98.
I>>>А я не про ваш код говорю, а про тот, который мне довелось видеть.
M_>>неплохая причина ругать язык

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>>Какой же он ЯВУ если в нем нет абстрагирования от вопросов связаных например с памятью а многие инструменты просто не работают ?
M_>>как-бы некоторый уровень абстрагирования есть. Если не изобретать ядерного реактора, то с распределением памяти не сталкиваешься.

I>Для начала надо на раз выучить и использовать RAII. Сам язык дает слишком большой простор.
Ну дык и мощное оружие в руки дают только подготовленным людям.

I>Парсить С++ код та еще задача. до сих пор нет нормального средства рефакторинга, которое было бы таким же доступным как и то что есть в решарпере.
Assist вполне покрывает 100% моих задач. Что еще такого нужно для С++?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

V>>Чем тебе STL-то не угодил? Где в нем опасность?
E>Очень легко написать очень неэффективный код. Предполагает очень умного и знающего пограммиста.
E>Собственно я отвечал на сообщение, где наличие STL упоминадось как недостаток С++.
E>Можно разработать менее кудрявый фреймворк, который будет не таким легко расширяемым и универсальным, но, зато, и не будет провоцировать написание неэффективного кода по незнанию...

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

ну ты понял, да?

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

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

DC>>>>>У нас их крайне мало.

Несмотря на то, что сначала это были xlc 5 и VC98.
I>>>>А я не про ваш код говорю, а про тот, который мне довелось видеть.
M_>>>неплохая причина ругать язык

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

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

Если хочешь что бы аналогия была полной, надо взять и создать в С++ сообществе инструмент с функциями МВД

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

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

C>>Есть стандартизованный D-BUS. Прямой аналог COM, в общем.+++
I>Ога, а ты COM то видел ? Сравни и не пори чушь
Мальчик, я COM не только видел, но и ещё с нуля писал OLE-контейнер.

COM:

hr = CoCreateInstance (pClsid,NULL,CLSCTX_LOCAL_SERVER,
         IID_IDispatch,
         (void FAR* FAR*)lpDispatch );

if (hr != S_OK)
 return (-1);

hr=lpDispatch->GetIDsOfNames(IID_NULL,&szStart, 1,LOCALE_SYSTEM_DEFAULT,&dispid);

if (hr != S_OK)
 return (-1);

    dispparams.rgvarg = &myargs[0];
    dispparams.rgvarg[0].vt = VT_I4;
    dispparams.rgvarg[0].iVal = 12345;
    dispparams.rgvarg[1].vt = VT_I4;
    dispparams.rgvarg[1].iVal = 67890;
    dispparams.cArgs = 2;
    dispparams.cNamedArgs = 0;

hr = lpDispatch->Invoke (dispid,IID_NULL,LOCALE_USER_DEFAULT,
DISPATCH_METHOD,&dispparams,NULL,NULL,NULL);

D-BUS

org::foo::bar::network *interface = 
    new org::foo::bar::network("org.foo.bar", "/network",
                            QDBusConnection::sessionBus(),
                            this);
interface->ping("kde.org");

или с более сложным примером: http://wiki.apertium.org/wiki/Compiling_a_C%2B%2B_D-Bus_program

//Имена, а не GUID'ы!
    static const char* TRANSLATE_SERVICE_NAME = "org.apertium.mode";
    static const char* TRANSLATE_OBJECT_PATH = "/";

    std::string mode;
    std::map< ::DBus::String, ::DBus::String> translate_options;
///....

    //Никаких CoCreateInstance - простые конструкторы!
    Translate translator(bus, TRANSLATE_OBJECT_PATH, TRANSLATE_SERVICE_NAME);
    //Да-да, мы передаём не жуткие SAFEARRAY и VARIANT, а самый обычный std::map
    std::cout << translator.translate(mode, translate_options, input.str())
              << std::endl;

I>D-Bus это докомовский период

Посткомовский. Там исправлены кретинизмы COMа.

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

I>>Парсить С++ код та еще задача. до сих пор нет нормального средства рефакторинга, которое было бы таким же доступным как и то что есть в решарпере.
CC>Assist вполне покрывает 100% моих задач. Что еще такого нужно для С++?

Я не сильно слежу за ассистом. он умеет ли он (2005я)

Без малого, я пользуюсь всем этим постоянно

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

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

C>>Стандарт де-факто — это gcc. Он достаточно backward compatible и его эмулирует icc.
C>>Более того, он даже кодифицирован: http://www.codesourcery.com/public/cxx-abi/abi.html#mangling
E>Так я про то же! Проблема с манглином -- надуманная!
Тем не менее, он менялся несколько раз. Скажем, gcc 2.95 и gcc 3.3 — несовместимы. А ещё на него влияют разные настройки (скажем, использование исключений).

Причём далеко не только на gcc. Про то как разные настройки выравнивания или "Treat wchar_t as built-in type" на MSVC ломают бинарную совместимость напомнить?

Поэтому на С++ особо и нет бинарных интерфейсов.

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

NBN>>Например?

Практики буквально на днях выясняли, что С++ таки самый лучший

___>Пруфлинк. Или нотариально заверенные скриншоты.

___>Примеров масса: С#, Nemerle, Lisp и многое. Если заведут старую пластинку про какой-нибудь драйвер, то уж лучше С.

Нравятся мне религиознутые теоретики

Ну попробуй с помощью шарпа напиши что-нибудь кроссплатформенное и не сферическое

Во, например, из последнего:
http://www.rsdn.ru/forum/pda/3671612.flat.aspx

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

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

I>В C# например пошли именно этим путем — облегчили работу людям которые пишут средства разработки.

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

E>Если ты не понял, то при чём тут несбыточное?
Объяснись тогда.

E>Да и пусть себе не входит. Вот если в Линуксе появится С++ API, в котором будет заданы правила декорирования, то все компиляторы под линукс легко смогут приделать опцию "придерживаться этих правил"...

В Линуксе "вдруг" ничего появиться не может. Линукс — это только ядро, а ядро правила декорирования не устанавливает.

V>>Во-во. Как бы ты взаимодействовал с этим кодом из С? Который декорировать не умеет никак?
E>Через переходники.
И прощай легаси драйверы и программы. Нафиг такое счастье.

E>Ну вот COM под виндой -- это пример того, как взяли в системе, да и стандаритизировали, фактически, то, как таблица виртуальных функций должна выглядеть. И ничего, всё у них получилось. Все компиллеры С++ под винду это дело поддержали...
КОМ в винде реализован на С. И его интерфейс — сишный. С++ тут вообще не при чем, точно такой же КОМ можно реализовать и в Линуксе.

F>А я как раз, было дело, руками лепил COM-интерфейс на C++.
F>И представлял он из себя ничто иное как C++ класс, у которого все методы — виртуальные.

Ты не понял, что ты сделал. КОМ — это сишный интерфейс, и реализован он на С.

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

I>>>Парсить С++ код та еще задача. до сих пор нет нормального средства рефакторинга, которое было бы таким же доступным как и то что есть в решарпере.
CC>>Assist вполне покрывает 100% моих задач. Что еще такого нужно для С++?

I>Я не сильно слежу за ассистом. он умеет ли он (2005я)
Не могу представить когда в C++ может понадобиться аналог пункта "Convert"

I>Помнится, один наш общий знакомый вещал что "не пользуемся рефакторингом потому что архитектура идеальная "

Я пользуюсь refactor rename, create implementation, create declaration, extract method
Вроде как всё.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>Если хочешь что бы аналогия была полной, надо взять и создать в С++ сообществе инструмент с функциями МВД
Дык есть! Нагадил мимо буфера — бдыщ!

Всё в продукте вторичном.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>Ога, а ты COM то видел ? Сравни и не пори чушь
C>Мальчик, я COM не только видел, но и ещё с нуля писал OLE-контейнер.

А по коду тобою показаному это не заметно. Это даже не смешно — самописный OLE-контейнер.
Чего ты хочешь показать на примере изобретения велосипеда ?

Ты сравнил бегемота с табуреткой. В своем примере на D-bus ты показал, что есть биндинги.
А слабо было показать биндинги для COM или твой огромный опыт написания велосипеда не включает это ?

Показать D-bus-аналог того кода, что ты привел для COM, вероятно помешала скромность

Ну да ладно, я давно в курсе что ты очень скромный.

вот тот же пример, что я показал ранее, с биндингами для ком

IServerPtr ptr;

ptr.CreateInstance(clsid);

_bstr_t bstr = ptr->GetStuff(s);

— при том появилоь это более 12 лет назад

>>D-Bus это докомовский период

C>Посткомовский. Там исправлены кретинизмы COMа.

Посткомовский он только по дате рождения

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

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

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

I>>В C# например пошли именно этим путем — облегчили работу людям которые пишут средства разработки.

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

.

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

кроме того, в .net много средтв которые теснят именно нативный C++ а не джаву.

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

I>>>>Парсить С++ код та еще задача. до сих пор нет нормального средства рефакторинга, которое было бы таким же доступным как и то что есть в решарпере.
CC>>>Assist вполне покрывает 100% моих задач. Что еще такого нужно для С++?

I>>Я не сильно слежу за ассистом. он умеет ли он (2005я)
CC>Не могу представить когда в C++ может понадобиться аналог пункта "Convert"

Ну так в с++ нет такого понятия как интерфейсы, проперти, индексеры, эвенты и тд.
Есть сущности аналогчные перечисленым, но на уровне инструментов они не поддерживаются, этот код ты лопатишь руками.

А что ассист то поддерживает из приведеного списка ?

I>>Помнится, один наш общий знакомый вещал что "не пользуемся рефакторингом потому что архитектура идеальная "

CC>Я пользуюсь refactor rename, create implementation, create declaration, extract method
CC>Вроде как всё.

этого мягко говоря мало.

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

I>>Если хочешь что бы аналогия была полной, надо взять и создать в С++ сообществе инструмент с функциями МВД
CC>Дык есть! Нагадил мимо буфера — бдыщ!

Всё в продукте вторичном.

Нету. Для полной аналогии говнокодер уличенный кем либо в сообществе С++ников должен понести административную или уголовную ответственность.

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

I>>>Ога, а ты COM то видел ? Сравни и не пори чушь
C>>Мальчик, я COM не только видел, но и ещё с нуля писал OLE-контейнер.
I>А по коду тобою показаному это не заметно. Это даже не смешно — самописный OLE-контейнер.
I>Чего ты хочешь показать на примере изобретения велосипеда ?
Нет, так как существующие контейнеры были недостаточны.

I>Ты сравнил бегемота с табуреткой. В своем примере на D-bus ты показал, что есть биндинги.
I>А слабо было показать биндинги для COM или твой огромный опыт написания велосипеда не включает это ?
Я лично всегда использую Comet:

    comet::bstr_t appID("SD");
    comet::bstr_t appName("StaffDirector Application");
    comet::bstr_t ticket;

    comet::QBXMLRPLib::IRequestProcessor2Ptr rqPtr(comet::QBXMLRPLib::RequestProcessor::create());
    rqPtr ->OpenConnection(appID, appName);
    // begin session
    ticket = rqPtr ->BeginSession(argv[1], comet::QBXMLRPLib::qbFileOpenDoNotCare);

I>Показать D-bus-аналог того кода, что ты привел для COM, вероятно помешала скромность

I>Ну да ладно, я давно в курсе что ты очень скромный.
То есть? Что именно нужно показать?

I>

I>IServerPtr ptr;
I>ptr.CreateInstance(clsid);
I>_bstr_t bstr = ptr->GetStuff(s);

I>- при том появилоь это более 12 лет назад
А теперь попробуй передать в метод карту. Как будешь её представлять? В виде двумерного SAFEARRAY (для которого в ATL нет нормальных байндингов)? А что будем делать с асинхронными вызовами (AKA посылка сообщений)? Напомнить какой это геморрой в COM?

А как насчёт out-of-proc серверов, напомнить кретинизм с их активацией, маршаллингом, ROT и прочими радостями?

>>>D-Bus это докомовский период

C>>Посткомовский. Там исправлены кретинизмы COMа.
I>Посткомовский он только по дате рождения

Нет, ещё и по удобсвту использования. Но тебе не понять, у тебя мозг вынул и выбросил сертефицированный представитель Microsoft.

В общем, твой тезис о том, что в Линуксе нет COM — банально неверен.

Вопрос имею.
А разве D-BUS — это не просто шина сообщений?

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

V>Вопрос имею.
V>А разве D-BUS — это не просто шина сообщений?
Ну так и COM — это просто формат на таблицу методов

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

I>>Objective-C тоже совместим с С, но при этом он настоящий ЯВУ.

D>Вы еще дрочите на мак? Тогда мы идем к Вам. Ты на нем хоть что нибудь писал, интересно?
Ну я писал, и тоже так считаю. Какие Ваши аргументы?

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

I>>>Я не сильно слежу за ассистом. он умеет ли он (2005я)
CC>>Не могу представить когда в C++ может понадобиться аналог пункта "Convert"

I>Ну так в с++ нет такого понятия как интерфейсы, проперти, индексеры, эвенты и тд.
I>Есть сущности аналогчные перечисленым, но на уровне инструментов они не поддерживаются, этот код ты лопатишь руками.
Лопатишь это как то громко сказано. В языке всей этой ботвы нет. Этот функционал обеспечивается библиотеками.

I>этого мягко говоря мало.
Для шарпа мало. Для С++ — достаточно.
Там в ассисте еще много всякой бороды есть, типа encapsulate field, change visibility, change signature (во, еще этой иногда пользуюсь), create from usage и т.п.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

C>Ну так и COM — это просто формат на таблицу методов

Ну все таки, технологии существенно разные. КОМ — это реализация объектно-ориентированной модели средствами С (что бы там не говорил Егор выше, которому с какого-то перепоя показалось, что КОМ — это С++).
Вызов по COM — это реальный вызов метода, in-proc или out-proc. В результате имеет счетчик ссылок и прочее.

Вызов по D-BUS — это передача сообщения по миддлеваре. В теории, ничего не измениться, если вместо D-BUS мы поставим тибку, например.
Я прав?

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

I>D-Bus это докомовский период

А тебе не кажется, что независимо от простейшего Hello DBUS и Hello COM, все эти вызовы прекрасно оборачиваются в одном методе, интерфейс которого можно подобрать так, что с ним будет достаточно удобно работать. И что вызо функции через COM, что через DBUS — в реальном коде все будет занимать одну простую строчку. Вернее скорее всего 2, одна — получение интерфейса, и вторая — вызов метода этого интерфейса. Или же планируется, что всем эти будут пользоваться индусы, которым платят за количество строчек кода?

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

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

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

I>>>В C# например пошли именно этим путем — облегчили работу людям которые пишут средства разработки.

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

.

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

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

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

V>Вызов по COM — это реальный вызов метода, in-proc или out-proc. В результате имеет счетчик ссылок и прочее.
А каким образом происходит вызов out-of-proc методов?

Hint: там ещё посылается оконное сообщение.

V>Вызов по D-BUS — это передача сообщения по миддлеваре. В теории, ничего не измениться, если вместо D-BUS мы поставим тибку, например.
V>Я прав?
Не совсем. D-BUS заточена под локальное использование, но в теории оно возможно.

Но кроме диспетчеризации сообщений, D-BUS ещё и стандартизует формат сообщений. Т.е. способ маршаллинга аргументов сообщений. Так что без проблем делается кросс-языковая интероперабельность.

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

I>>Показать D-bus-аналог того кода, что ты привел для COM, вероятно помешала скромность

I>>Ну да ладно, я давно в курсе что ты очень скромный.
C>То есть? Что именно нужно показать?

А что мешало это разу сделать ? Вместо этого ты нагородил какой то бред с IDispatch

I>>

I>>IServerPtr ptr;
I>>ptr.CreateInstance(clsid);
I>>_bstr_t bstr = ptr->GetStuff(s);

I>>- при том появилоь это более 12 лет назад
C>А теперь попробуй передать в метод карту. Как будешь её представлять? В виде двумерного SAFEARRAY (для которого в ATL нет нормальных байндингов)? А что будем делать с асинхронными вызовами (AKA посылка сообщений)? Напомнить какой это геморрой в COM?

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

C>А как насчёт out-of-proc серверов, напомнить кретинизм с их активацией, маршаллингом, ROT и прочими радостями?

все это _было_

C>Нет, ещё и по удобсвту использования. Но тебе не понять, у тебя мозг вынул и выбросил сертефицированный представитель Microsoft.
C>В общем, твой тезис о том, что в Линуксе нет COM — банально неверен.

На виндовсе COM имеет отличную поддержку и на .Net и в Delphi том же, а в линуксе это yet another ipc.

Вот когда D-bus дорастет до стандарта, как это было с COM, тогда и поговорим.

C>А каким образом происходит вызов out-of-proc методов?
А in-proc?

C>Hint: там ещё посылается оконное сообщение.
Ну да.

V>>Вызов по D-BUS — это передача сообщения по миддлеваре. В теории, ничего не измениться, если вместо D-BUS мы поставим тибку, например.
V>>Я прав?
C>Не совсем. D-BUS заточена под локальное использование, но в теории оно возможно.
Тибка тоже отлично работает локально.

C>Но кроме диспетчеризации сообщений, D-BUS ещё и стандартизует формат сообщений. Т.е. способ маршаллинга аргументов сообщений. Так что без проблем делается кросс-языковая интероперабельность.
И тибка делает то же самое.

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

I>>D-Bus это докомовский период

E>А тебе не кажется, что независимо от простейшего Hello DBUS и Hello COM, все эти вызовы прекрасно оборачиваются в одном методе, интерфейс которого можно подобрать так, что с ним будет достаточно удобно работать. И что вызо функции через COM, что через DBUS — в реальном коде все будет занимать одну простую строчку. Вернее скорее всего 2, одна — получение интерфейса, и вторая — вызов метода этого интерфейса. Или же планируется, что всем эти будут пользоваться индусы, которым платят за количество строчек кода?

COM в первую очередь это стандарт а не "yet another ipc"

Соответсвенно, как стандарт, имеет отличную поддержку в .Net

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

I>>>>Я не сильно слежу за ассистом. он умеет ли он (2005я)
CC>>>Не могу представить когда в C++ может понадобиться аналог пункта "Convert"

I>>Ну так в с++ нет такого понятия как интерфейсы, проперти, индексеры, эвенты и тд.
I>>Есть сущности аналогчные перечисленым, но на уровне инструментов они не поддерживаются, этот код ты лопатишь руками.
CC>Лопатишь это как то громко сказано. В языке всей этой ботвы нет. Этот функционал обеспечивается библиотеками.

Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.

CC>Для шарпа мало. Для С++ — достаточно.
CC>Там в ассисте еще много всякой бороды есть, типа encapsulate field, change visibility, change signature (во, еще этой иногда пользуюсь), create from usage и т.п.

Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?

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

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

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

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

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

Ну вот щас Оракл покажет, как надо

I>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.
Вот ты мне можешь объяснить, зачем нужен такой уродец, как property?

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

CC>>Для шарпа мало. Для С++ — достаточно.
CC>>Там в ассисте еще много всякой бороды есть, типа encapsulate field, change visibility, change signature (во, еще этой иногда пользуюсь), create from usage и т.п.

I>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?
на работе не самый свежий ассист стоит.
глянь на оффсайте, например тут:
http://wholetomato.com/products/default.asp
http://wholetomato.com/products/featureRefactoring.asp

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.
V>Вот ты мне можешь объяснить, зачем нужен такой уродец, как property?

За тем, что геттер и сеттер собраны вместе и это очень удобно для читаемости/писаемости кода и для инструментов

Например есть

someObj.Prop = something;

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

Что делает инструмент ? Правильно, предлагает создать сеттер, более того, он его и напишет за меня.

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

и вообще, всех действий нужно вдвое меньше, чем в джаве без пропертей

V>>Вот ты мне можешь объяснить, зачем нужен такой уродец, как property?

I>За тем, что геттер и сеттер собраны вместе и это очень удобно для читаемости/писаемости кода и для инструментов
Геттеры и сеттеры не нужны. Вообще. Приведи пример простого класса, для которого ты считаешь нужными property, и я покажу тебе, почему без них лучше.

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

C>>А каким образом происходит вызов out-of-proc методов?
V>А in-proc?
in-proc его обычно не используют (а смысл?). Хотя можно, он просто будет так же как и COM примерно работать.

C>>Но кроме диспетчеризации сообщений, D-BUS ещё и стандартизует формат сообщений. Т.е. способ маршаллинга аргументов сообщений. Так что без проблем делается кросс-языковая интероперабельность.
V>И тибка делает то же самое.
Ну вот как стандарт Тибки станет использоваться в почти всех линуксовых программах — так она и заменит D-BUS

C>Ну вот как стандарт Тибки станет использоваться в почти всех линуксовых программах — так она и заменит D-BUS

Это вряд ли. Тибка дорогая.
Я просто пытался показать, что технологии КОМ и ДБАС — разные, хотя и обеспечивают похожую функцуиональность.

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

C>>Ну вот как стандарт Тибки станет использоваться в почти всех линуксовых программах — так она и заменит D-BUS

V>Это вряд ли. Тибка дорогая.
V>Я просто пытался показать, что технологии КОМ и ДБАС — разные, хотя и обеспечивают похожую функцуиональность.
Они разные, но в то же время похожие. Просто в COM упор идёт на in-proc, а маршаллинг out-of-proc вызовов и IDispatch добавлены как afterthought. В D-BUS ровно наоборот — он затачивался под out-of-proc работу и удобные динамические вызовы, а COM-подобные интерфейсы были добавлены уже как дополнительное средство для ускорения работы.

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

I>>За тем, что геттер и сеттер собраны вместе и это очень удобно для читаемости/писаемости кода и для инструментов
V>Геттеры и сеттеры не нужны. Вообще.

Например, генерим какой класс по базе, это около 2-3 кликов мышом

получаетяс нечто вроде

class MegaItem
{
...

public string SomeField {get;set;}
public string SomeField2 {get;set;}
public string SomeField3 {get;set;}

...
}

далее, получаем инстанц и делаем следующее

MegaItem item = dbMgr.GetMegaItem(query);

и делаем следующее

_propertyGrid.DataSource = item;

где _propertyGrid это экземпляр пропертигрида

в итоге получаем вот ткое представление

название — Хуман ридабл строка для конкретной проперти (строка берется из Display Proxy) : значение (берётся из проперти)

А вообще лучше расскажи, чем ты собираешься заменить проперти в WPF

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

Например System.Drawing.Graphics

интересуют вот эти

Graphics.CompositingQuality
Graphics.SmoothingMode
Graphics.InterpolationMode
Graphics.TextRenderingHint

или System.Rectangle — там сразу ясно какие

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

I>А вообще лучше расскажи, чем ты собираешься заменить проперти в WPF
Что это такое?

I>или System.Rectangle — там сразу ясно какие
Я понятия не имею, что такое System.Rectangle. См. выше.

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

I>>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?
CC>на работе не самый свежий ассист стоит.
CC>глянь на оффсайте, например тут:
CC>http://wholetomato.com/products/featureRefactoring.asp

Короче говоря — ничего нет

Нужны высокоуровневые средтва, рефакторинг тот же.

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

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

B>>На практике получается, что объяснить программистам, как писать компактный и производительный код на С++ сложнее, чем запретить им пользоваться чем-либо кроме C. Увы.

E>Казалось бы, запретить вообще stl нафиг и разарботать своё, безопасное...

Зачем запрещать? Напишите свою библиотеку, лучше STL. Выложите на SourceForge, напишите по ней с десяток статей и радуйтесь. А на практике получается, что народ, не способный написать нормальный код с использованием STL, пишет свои библиотеки, по кривости и глючности превосходящие STL в разы...

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

F>>А я как раз, было дело, руками лепил COM-интерфейс на C++.
F>>И представлял он из себя ничто иное как C++ класс, у которого все методы — виртуальные.

V>Ты не понял, что ты сделал. КОМ — это сишный интерфейс, и реализован он на С.
COM — это тезнология, не имеющая формально отношения к используемому языку. Но, для облегчения жизни разработчикам на С++ формат интерфейсов соответствует С++ному. В итоге, это позволяет писать на С++ код вида:

class CSomething : ISomething
{
public:
  HRESULT __stdcall Method1();
  HRESULT __stdcall Method2();
};

ISomething *CreateSomething()
{
  return new CSomething;
}

Дюбители "потрахаться с компилятором", безусловно, могут написать на С:

struct CSomething
{
  struct ISomething intf;
};

HRESULT __stdcall CSomething_Method1(struct CSomething *pSomething);
HRESULT __stdcall CSomething_Method2(struct CSomething *pSomething);

struct ISomething *CreateSomething()
{
  struct CSomething *p = (struct CSomething *)malloc(sizeof(struct CSomething));
  p->intf.Method1 = &CSomething_Method1;
  p->intf.Method2 = &CSomething_Method2;
  return (struct ISomething *)p;
}

Результат тот же, а писанины в 2 раза больше. Зато можно почувствовать себя "крутым перцем, пишущим на низком уровне". Детский сад, короче.

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

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

Т.е. показать тебе именно пример где проперти не надо ?

I>>А вообще лучше расскажи, чем ты собираешься заменить проперти в WPF
V>Что это такое?

Windows Presentation Framework

I>>или System.Rectangle — там сразу ясно какие
V>Я понятия не имею, что такое System.Rectangle. См. выше.

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

Здравствуйте, Ikemefula, Вы писали:
CC>>http://wholetomato.com/products/featureRefactoring.asp
I>Короче говоря — ничего нет

I>Нужны высокоуровневые средтва, рефакторинг тот же.
Как будто тот же решарпер умеет что-то принципиально более сложное.

B>COM — это тезнология, не имеющая формально отношения к используемому языку. Но, для облегчения жизни разработчикам на С++ формат интерфейсов соответствует С++ному. В итоге, это позволяет писать на С++ код вида:

Напрямую — не позволяет. COM написан на С, там манглинга (вспомни, с чего начался топик) нет. Только через С++ биндинги.

I>Т.е. показать тебе именно пример где проперти не надо ?
То есть, property нужен только при работе с базами данных?

I>Windows Presentation Framework
Ничего про нее не знаю.

I>Я уже понял, что ты хотел сказать — в твоем коде/области проперти не нужны. Вполне возможно оно и так.
Нет, ты покажи мне код, где они нужны. Пока что ты показал только какое-то непонятное месиво, посвященное базам данных.

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

I>>Короче говоря — ничего нет

I>>Нужны высокоуровневые средтва, рефакторинг тот же.
MC>Как будто тот же решарпер умеет что-то принципиально более сложное.

Открой ссылку для асиста, открой картинку что я показал, сравни и напиши сюда свое мнение

"Как будто" — так и я умею. Смотри, как ловко:

Как будто нет ?

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

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

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

I>>>Здравствуйте, труженик села, Вы писали:

PD>>>>>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.
I>>>>>Это как бы ЯВУ, на самом дело недо-ЯВУ.
ТС>>>>Совместимость с C делает его недо-ЯВУ.
B>>Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет?

___>Позволяет. Но некоторые языки позволяют делать это лучше.

B>>Код более читабелен, по сравнению с альтернативами?

___>Код читабелен? Бу-га-га

___>На С++ код конечно читабелен. По сравнению с Брейнфаком. Но не более.
Вы про "среднюю температуру по больнице"? Или читабельность кода с 20 вложенными шаблонами равна читабельности кода, состоящего из пары классов, реализующих простой интерфейс?
Можно подумать, на C индусы не пишут

http://opensource.apple.com/source/procmail/procmail-1.2/procmail/src/procmail.c

B>>Производительность не меньше? Какие тогда проблемы юзать язык в тех задачах, где от него есть польза, забив, труъ ли это ЯВУ? Или надо шашечки, а не ехать?
___>Ехать. Но с комфортом.
Приведите пример задачи, которую нельзя "некриво" реализовать на С++ и я удивлю вас контрпримером

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

B>>COM — это тезнология, не имеющая формально отношения к используемому языку. Но, для облегчения жизни разработчикам на С++ формат интерфейсов соответствует С++ному. В итоге, это позволяет писать на С++ код вида:

V>Напрямую — не позволяет. COM написан на С, там манглинга (вспомни, с чего начался топик) нет. Только через С++ биндинги.
Причем здесь манглинг, если взаимодействие с компонентами реализуется посредством интерфейсов, а не эскпортированием методов по имени? А то, что системные функции COM незаманглены, всего лишь означает extern "C" при объявлении оных и совсем не говорит, что они написаны на C.

Здравствуйте, Ikemefula, Вы писали:
I>>>Нужны высокоуровневые средтва, рефакторинг тот же.
MC>>Как будто тот же решарпер умеет что-то принципиально более сложное.
I>Открой ссылку для асиста, открой картинку что я показал, сравни и напиши сюда свое мнение
Ну у решарпера на твоем скриншоте количество пунктов меню набивается за счет "convert шило to мыло" (например, абстрактный класс в интерфейс, ну и туда же преобразования пропертей — которые к C++ неприменимы). А так, что CreatorCray перечислил — это и есть основные возможности — и они заявлены. Не знаю, насколько это в ассисте хорошо работает, просто в этой теме шарповый рефакторинг почему-то преподносится как что-то неземное.

B>Причем здесь манглинг, если взаимодействие с компонентами реализуется посредством интерфейсов, а не эскпортированием методов по имени? А то, что системные функции COM незаманглены, всего лишь означает extern "C" при объявлении оных и совсем не говорит, что они написаны на C.
Сдается мне, ты вообще не понимаешь, о чем идет речь в это дискуссии.

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

E>>Вот, например, к акве-какаве в МэкОС Х тоже никак, кроме как через ОбжективС не достучишься.
LS>Если я правильно помню, все же можно — вроде, там есть некая библиотека, позволяющая C-коду взаимодействовать с Objective-C объектами.

А ты ей пользовался? Я вот пользовался. Всё равно удобно иметь кусок на Objective-C, на самом деле.
Для связи с C++ объектами тоже можно аналогичную библиотеку написать...

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

I>не между средами, а между компиляторами.
Не только компиляторами. COM-объект можно и из Word'а из VBA дёрнуть, например...

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

M_>ну ты понял, да?
Не я тут высказывал идею, что С лучше С++ из-за наличия в последнем STL...

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

C>Причём далеко не только на gcc. Про то как разные настройки выравнивания или "Treat wchar_t as built-in type" на MSVC ломают бинарную совместимость напомнить?

C>Поэтому на С++ особо и нет бинарных интерфейсов.

Ну так на С могли бы быть ровно те же проблемы. Просто у системы есть API на С, и нет API на С++
Было бы API на С++ -- там бы подумали каким образом декорировать имена, ну и во всех бы компиляторах появился бы ещё один __declspec...

Другое дело, что декорирование имён совсем и не главная проблема. Главная проблема -- это аллокация памяти, исключения и т. д...

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

V>Ты не понял, что ты сделал. КОМ — это сишный интерфейс, и реализован он на С.

И, тем не менее, из С++ COM-интерфейс виден, как объект с кучей виртуальных методов...

Из любой реализации под С++ под винду, обрати внимание

E>И, тем не менее, из С++ COM-интерфейс виден, как объект с кучей виртуальных методов...

Нет. Только при использовании биндингов. Сам по себе он сишный.

E>Из любой реализации под С++ под винду, обрати внимание

Потому, что он сишный.

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

B>Зачем запрещать? Напишите свою библиотеку, лучше STL. Выложите на SourceForge, напишите по ней с десяток статей и радуйтесь. А на практике получается, что народ, не способный написать нормальный код с использованием STL, пишет свои библиотеки, по кривости и глючности превосходящие STL в разы...

Имелось в виду, запретить в проекте, для которого выбирают язык...

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

E>>Из любой реализации под С++ под винду, обрати внимание

V>Потому, что он сишный.

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

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

Ты правда не понимаешь? КОМ — это приложение, реализованное на С. Не имеет никакого отношения к С++, и зачем ты его здесь приплетаешь, неясно.

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

C>>Причём далеко не только на gcc. Про то как разные настройки выравнивания или "Treat wchar_t as built-in type" на MSVC ломают бинарную совместимость напомнить?
C>>Поэтому на С++ особо и нет бинарных интерфейсов.
E>Ну так на С могли бы быть ровно те же проблемы. Просто у системы есть API на С, и нет API на С++
Откуда они на С возьмутся? Экспортируемые функции С не содержат полных сигнатур, так что им однофигственно что у тебя wchar_t — это отдельный тип, а не typedef для short'а.

E>Было бы API на С++ -- там бы подумали каким образом декорировать имена, ну и во всех бы компиляторах появился бы ещё один __declspec...
E>Другое дело, что декорирование имён совсем и не главная проблема. Главная проблема -- это аллокация памяти, исключения и т. д...

Как раз твоя "главная проблема" на том же Линуксе вообще не стоит.

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

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

E>>>Вот, например, к акве-какаве в МэкОС Х тоже никак, кроме как через ОбжективС не достучишься.
LS>>Если я правильно помню, все же можно — вроде, там есть некая библиотека, позволяющая C-коду взаимодействовать с Objective-C объектами.

E>А ты ей пользовался? Я вот пользовался. Всё равно удобно иметь кусок на Objective-C, на самом деле.

Удобно, кто бы спорил.

E>Для связи с C++ объектами тоже можно аналогичную библиотеку написать...

Для С++ можно написать, а там уже есть.

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

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

V>Ты правда не понимаешь? КОМ — это приложение, реализованное на С. Не имеет никакого отношения к С++, и зачем ты его здесь приплетаешь, неясно.

Я правда не понимаю, откуда следует выделенное.

А привёл я его тут, как пример успешной фиксации платформой одной из особенностей реализации С++...

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

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

C>>>Причём далеко не только на gcc. Про то как разные настройки выравнивания или "Treat wchar_t as built-in type" на MSVC ломают бинарную совместимость напомнить?
C>>>Поэтому на С++ особо и нет бинарных интерфейсов.
E>>Ну так на С могли бы быть ровно те же проблемы. Просто у системы есть API на С, и нет API на С++
C>Откуда они на С возьмутся? Экспортируемые функции С не содержат полных сигнатур, так что им однофигственно что у тебя wchar_t — это отдельный тип, а не typedef для short'а.
Зато им не однофигственно сколько байт из стека доставать

C>Как раз твоя "главная проблема" на том же Линуксе вообще не стоит.
Как так "не стоит"? Исключения могут летать между разными версиями gcc? Или, аллокации можно передавать?

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

E>>Для связи с C++ объектами тоже можно аналогичную библиотеку написать...
LS>Для С++ можно написать, а там уже есть.

Ну так и системных API на плюсах мало... GDI+ разве отчасти...

E>Я правда не понимаю, откуда следует выделенное.
Скажем так, на чем реализован КОМ, я точно не знаю. Но полагаю, что на С, как и вся Windows. Но его интерфейсы — сишные. И это следует из спецификации.

E>А привёл я его тут, как пример успешной фиксации платформой одной из особенностей реализации С++...
Ну ты и джаву мог привести с тем же успехом. И питон. И .Нет, прости господи.

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

E>>А привёл я его тут, как пример успешной фиксации платформой одной из особенностей реализации С++...
V>Ну ты и джаву мог привести с тем же успехом. И питон. И .Нет, прости господи.

А ты перечитай моё первое сообщение, где я приводил примеры и COM в том числе

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

C>>Откуда они на С возьмутся? Экспортируемые функции С не содержат полных сигнатур, так что им однофигственно что у тебя wchar_t — это отдельный тип, а не typedef для short'а.
E>Зато им не однофигственно сколько байт из стека доставать

Ну так то было решено ещё в эпоху PASCAL'я.

C>>Как раз твоя "главная проблема" на том же Линуксе вообще не стоит.
E>Как так "не стоит"? Исключения могут летать между разными версиями gcc? Или, аллокации можно передавать?

Да, и можно.

E>А ты перечитай моё первое сообщение, где я приводил примеры и COM в том числе

То есть, ты хотел сказать, что есть и другие реализации ООП, кроме С++? Тогда твое высказывание тривиально.

MK>А что в них уродливого?
Все.

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

E>>Зато им не однофигственно сколько байт из стека доставать

C>Ну так то было решено ещё в эпоху PASCAL'я.

Блин! Так я про то же и говорю, что в С свои проблемы бинарной совместимости были, и что они были успешно решены. Было бы надо -- и с С++ справились бы...

C>>>Как раз твоя "главная проблема" на том же Линуксе вообще не стоит.
E>>Как так "не стоит"? Исключения могут летать между разными версиями gcc? Или, аллокации можно передавать?

C>Да, и можно.

Чего? Как оно нужный ::operator delete найдёт?
Про исключения тоже забавно. Из какого именно std::excegtion оин будут унаследованы? От STL которой версии?

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

V>То есть, ты хотел сказать, что есть и другие реализации ООП, кроме С++? Тогда твое высказывание тривиально.
То что я хотел сказать, я сказал уже много раз.

Проблемы с декорайией С++ имён не так страшны, чтобы помешать использовать С++ в качестве языка части API OS

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

E>То что я хотел сказать, я сказал уже много раз.

Проблемы с декорайией С++ имён не так страшны, чтобы помешать использовать С++ в качестве языка части API OS

Я так и не смог понять, почему для иллюстрации этого тезиса ты выбрал КОМ, который НЕ НАПИСАН НА С++, не экспортирует С++ интерфейсы и вообще не имеет отношения к С++.

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

MK>>А что в них уродливого?
V>Все.
Слил?

MK>Слил?
Это смотря кто.

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

V>Я так и не смог понять, почему для иллюстрации этого тезиса ты выбрал КОМ, который НЕ НАПИСАН НА С++, не экспортирует С++ интерфейсы и вообще не имеет отношения к С++.

Потому, что COM, тем не менее, смог зафиксировать формат таблицы виртуальных функций, которому следуют ВСЕ компиляторы С++ под винду...

E>Потому, что COM, тем не менее, смог зафиксировать формат таблицы виртуальных функций, которому следуют ВСЕ компиляторы С++ под винду...

Да нет же! КОМ вообще не имеет дела с виртуальными таблицами, потому что НЕ экспортирует С++-классы. Программы на КОМ можно писать, например, на VB, в котором никаких виртуальных таблиц нет вообще.

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

V>>Я так и не смог понять, почему для иллюстрации этого тезиса ты выбрал КОМ, который НЕ НАПИСАН НА С++, не экспортирует С++ интерфейсы и вообще не имеет отношения к С++.
E>Потому, что COM, тем не менее, смог зафиксировать формат таблицы виртуальных функций, которому следуют ВСЕ компиляторы С++ под винду...

Странно, но у gcc абсолютно такие же виртуальные таблицы. Странно, да?

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

E>>>Зато им не однофигственно сколько байт из стека доставать

C>>Ну так то было решено ещё в эпоху PASCAL'я.
E>Блин! Так я про то же и говорю, что в С свои проблемы бинарной совместимости были, и что они были успешно решены. Было бы надо -- и с С++ справились бы...

Эти проблемы на пару порядков сложности различаются. Описание calling convention для С занимает страничку, описание ABI для C++ — около 500 (с учётом исключений, множественного наследования и всяких dynamic_cast).

E>>>Как так "не стоит"? Исключения могут летать между разными версиями gcc? Или, аллокации можно передавать?

C>>Да, и можно.
E>Чего? Как оно нужный ::operator delete найдёт?
Они forward compatible в libstdc++.

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

E>>Чего? Как оно нужный ::operator delete найдёт?
C>Они forward compatible в libstdc++.

Ха! А если я перекрою, например?

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

C>Странно, но у gcc абсолютно такие же виртуальные таблицы. Странно, да?
Не абсолютно, но похожие.
А вот с точки зрения COM'а -- точно такие же, кстати...

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

E>>Потому, что COM, тем не менее, смог зафиксировать формат таблицы виртуальных функций, которому следуют ВСЕ компиляторы С++ под винду...

V>Да нет же! КОМ вообще не имеет дела с виртуальными таблицами, потому что НЕ экспортирует С++-классы. Программы на КОМ можно писать, например, на VB, в котором никаких виртуальных таблиц нет вообще.

И что? Как то вообще связано с моим утверждением?

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

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

E>>>Чего? Как оно нужный ::operator delete найдёт?
C>>Они forward compatible в libstdc++.
E>Ха! А если я перекрою, например?
Будешь сам себе злобный Буратино.

E>Я не утверждаю, что COM на С++ написан или на него ориентирован. Я всего лишь утверждаю, что он задал формат таблиц виртуальных функций под винду...

Твое утверждение необоснованно.

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

I>>>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?
CC>>на работе не самый свежий ассист стоит.
CC>>глянь на оффсайте, например тут:
CC>>http://wholetomato.com/products/featureRefactoring.asp
I>Короче говоря — ничего нет

I>Нужны высокоуровневые средтва, рефакторинг тот же.
Зачем?
Объясни?
Какие средства надо? Что у тя входит в рефакторинг?
Ты не меряй то, что надо для шарпа на плюсы.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

E>>>>Чего? Как оно нужный ::operator delete найдёт?
C>>>Они forward compatible в libstdc++.
E>>Ха! А если я перекрою, например?
C>Будешь сам себе злобный Буратино.
ага вы можете выбрать себе любой цвет при условии что он черный

И соответственно определить любой operator delete при условии что он тождественно равный free()

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

B>>Причем здесь манглинг, если взаимодействие с компонентами реализуется посредством интерфейсов, а не эскпортированием методов по имени? А то, что системные функции COM незаманглены, всего лишь означает extern "C" при объявлении оных и совсем не говорит, что они написаны на C.
V>Сдается мне, ты вообще не понимаешь, о чем идет речь в это дискуссии.
Сдается мне, что я опроверг все твои аргументы и ты перешел на "ты ваще с какого района" за неимением ничего лучшего.

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

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

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

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

B>>>>Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет?

___>>>Позволяет. Но некоторые языки позволяют делать это лучше.

NBN>>Например?

Практики буквально на днях выясняли, что С++ таки самый лучший

___>Пруфлинк. Или нотариально заверенные скриншоты.

___>Примеров масса: С#, Nemerle, Lisp и многое. Если заведут старую пластинку про какой-нибудь драйвер, то уж лучше С.
Я понимаю, Nemerle может служить примером. Но зачем писать Lisp? Почему его вообще всегда упоминают, а забывают про какую нибудь Аду или PL/1? Это же всё устаревшие языки программирования.

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

I>>Т.е. показать тебе именно пример где проперти не надо ?
V>То есть, property нужен только при работе с базами данных?

I>>Windows Presentation Framework
V>Ничего про нее не знаю.

I>>Я уже понял, что ты хотел сказать — в твоем коде/области проперти не нужны. Вполне возможно оно и так.
V>Нет, ты покажи мне код, где они нужны. Пока что ты показал только какое-то непонятное месиво, посвященное базам данных.

Например, такая простая ситуация. Есть GUI элемент Button. В процессе выполнения программы нам нужно передвинуть кнопку на форме. Положим, по координате X. С использованием Property это будет выглядеть так: button1.x = <новое значение>. Без button1.setX(<новое значение>). Кому то нравится первый вариант. Если отрицать это, и рассуждать в том же духе, что синтаксический сахар не нужен, можно оставаться программировать на ассемблере.

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

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

CC>>>Для шарпа мало. Для С++ — достаточно.
CC>>>Там в ассисте еще много всякой бороды есть, типа encapsulate field, change visibility, change signature (во, еще этой иногда пользуюсь), create from usage и т.п.

I>>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?
CC>на работе не самый свежий ассист стоит.
CC>глянь на оффсайте, например тут:
CC>http://wholetomato.com/products/default.asp
CC>http://wholetomato.com/products/featureRefactoring.asp
Ассист бяка. Он на сложном коде, насыщенном шаблонами глючит.

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

B>C++ позволяет сильно автоматизировать и упрощать многие вещи (та же работа со строками или STL). Это не означает, что на C++ нельзя написать код, идентичный по производительности коду на C и при этом занимающий в 2 раза меньше строк. Но означает, что для того, чтобы написать громоздкое приложение на C надо писать много кода, на C++ для этого достаточно пару раз не задуматься о последствиях и поюзать стандартные конструкции кривым способом.
B>Например, хэш-таблицу для повторяющихся строк на C можно реализовать, вручную распихав строки в едином блоке без дублирования совпадающих подстрок и сделав вычисление хэшей. Займет это N строк. На C++ все можно реализовать аналогично низкоуровнево, займет это меньше N строк и будет иметь красивую модульную структуру. НО всегда найдется программист, который поюзает std::map<std::string, std::string>, не вьезжая в принцип его работы, чем увеличит требуемый размер памяти в разы.

На самом деле, с точки зрения выразительности запись std::map<std::string, std::string> гораздо лучше. И нужно писать именно так (но не в случае с STL

). Проблема в том, что STL довольно хреновая библиотека. И я вообще не знаю случаев, когда её использование было бы оптимальным решением. Но вообще говоря, можно реализовать библиотеку контейнеров (назовем её my_lib) так, чтобы использования объекта с типом my_lib::map<my_lib::string, my_lib:string> транслировалось в эффективный код.
Во первых, нужно эффективно реализовать строку. Что я имею ввиду? Обычно строки используемые в таких случаях имеют маленькую длину. В таком случае можно применить слудующую оптимизацию: строка до определенного размера будет хранится не в динамической памяти, а в массиве фиксированной длины, являющимся членом класса строка. Размер массива можно задавать через параметр шаблона, для этого определение класса строка должно иметь вид template<unsigned N = sizeof(char*)> class string;
Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.
И можно придумать множество параметров, в соответствии с которыми будут настраиваться контейнеры.
В итоге процесс программирования в таком случае можно будет поделить на две части. 1 — Написание логики работы программы. 2 — оптимизация программы путем подбора параметров контейнеров.
Только почему то господину Степанову это совершенно не пришло в голову...

B>На практике получается, что объяснить программистам, как писать компактный и производительный код на С++ сложнее, чем запретить им пользоваться чем-либо кроме C. Увы.

WTF, что это за язык?!

void split(int *arr)
  requires(is_object_root(as_array(arr, 100)))
  writes(extent(as_array(arr, 100)))
{
  split_array(as_array(arr, 100), 50);
  split_array(as_array(arr+50, 50), 25);
  split_array(as_array(arr, 50), 25);
  split_array(as_array(arr+25, 25), 10);
}

void splitAndJoin(int *arr)
  requires(is_object_root(as_array(arr, 100)))
  writes(extent(as_array(arr, 100)))
{
  split_array(as_array(arr, 100), 50);
  join_arrays(as_array(arr, 50), as_array(arr+50, 50));
}

void join(int *arr1, int *arr2)
  requires(arr1 + 100 == arr2)
  requires(is_object_root(as_array(arr1, 100)))
  requires(is_object_root(as_array(arr2, 32)))
  writes(extent(as_array(arr1, 100)), extent(as_array(arr2, 32)))
{
  join_arrays(as_array(arr1, 100), as_array(arr2, 32));
}

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

A>Например, такая простая ситуация. Есть GUI элемент Button. В процессе выполнения программы нам нужно передвинуть кнопку на форме.
A>Положим, по координате X. С использованием Property это будет выглядеть так: button1.x = <новое значение>. Без button1.setX(<новое значение>).
По мне так это абсолютно одно и то же. Синтаксический сахар и не более того.
Я так понимаю проперти тебе там понадобилось для того, чтоб выполнить кроме самого изменения координаты еще и перерисовку (immediate или deferred, неважно).
И тут и там вызов функции, только в случае с проперти он неявный. Что меня регулярно сильно раздражало при разборе индусокода на шарпе: эти уникумы любят пихать в сеттеры/геттеры дохренища кода, который делает много чего левого, не относящегося собственно к этой проперти.

A>рассуждать в том же духе, что синтаксический сахар не нужен, можно оставаться программировать на ассемблере.
проперти перед вызовом функции по мне так выигрывают совсем ничтожный мизер "синтаксического оверхеда" (С) (R) (ТМ), при этом иногда затрудняя читабельность кода, т.к. скрывают реальную работу, происходящую в этом месте. Как на глаз отличить присвоение проперти и присвоение переменной? Каждый раз лазить и смотреть есть ли сеттер?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>Открой ссылку для асиста, открой картинку что я показал, сравни и напиши сюда свое мнение
Дык существенная часть того что там он умеет для С++ попросту нафиг не нужно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

MC>просто в этой теме шарповый рефакторинг почему-то преподносится как что-то неземное.
Ну, надо ж им чем то гордиться.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>Т.е. показать тебе именно пример где проперти не надо ?
V>То есть, property нужен только при работе с базами данных?

Необязательно.

I>>Windows Presentation Framework
V>Ничего про нее не знаю.

Загляни в какой толковый туториал по MVVM.

I>>Я уже понял, что ты хотел сказать — в твоем коде/области проперти не нужны. Вполне возможно оно и так.
V>Нет, ты покажи мне код, где они нужны. Пока что ты показал только какое-то непонятное месиво, посвященное базам данных.

Контролы в WPF и тот же System.Rectangle никакого отношения к БД не имеют.

Есть такой класс как System.Windows.Forms.Control и его наследники. Куда деть тамошние проперти ?

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

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

I>>>>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?
CC>>>на работе не самый свежий ассист стоит.
CC>>>глянь на оффсайте, например тут:
CC>>>http://wholetomato.com/products/featureRefactoring.asp
I>>Короче говоря — ничего нет

I>>Нужны высокоуровневые средтва, рефакторинг тот же.
CC>Зачем?
CC>Объясни?
CC>Какие средства надо? Что у тя входит в рефакторинг?

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

Есть куча кода, который исправно работал где то с 2003го года, а сейчас появились новые требования для него.

Или такая задача — упрощения имеющегося кода.

Можно, конечно, подойти по понЭрски — все переписать заново, с нуля или около того.

Но гораздо проще, быстре и надежнее будет сделать рефакторинг.

Практически везде нужно

1. выделение базового класса/интерфейса
2. перемещение методов по иерархии
3. использование базового класса

еще очень сильно не хватает "преобразование метода в класс"
и вообще очень много чего не хватает

при этом Решарпер предоставляет много средств которые не показыны в меню что я привел, например создание наследника, генерацию конструкторов и многое другое

заметь — выделение метода я упомянул только здесь.

CC>Ты не меряй то, что надо для шарпа на плюсы.

Рефакторинг нужен независимо от языка.

В с++ мощные средства рефакторинга будут работать с такой же скоростью как и компилер

потому ты их там и не видишь.

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

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

I>>Открой ссылку для асиста, открой картинку что я показал, сравни и напиши сюда свое мнение
CC>Дык существенная часть того что там он умеет для С++ попросту нафиг не нужно.

Отчасти это верно, потому что С++ уже вытеснен в дотаточно узкую нишу.

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

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

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

B>>Сдается мне, что я опроверг все твои аргументы и ты перешел на "ты ваще с какого района" за неимением ничего лучшего.
V>Господь с тобой, какие мои аргументы ты опроверг? Давай сначала, а то уже запуталось все.
V>Итак, с какими конкретно моими тезисами ты не согласен и почему?

B>>В итоге, это позволяет писать на С++ код вида:
V>Напрямую — не позволяет. COM написан на С, там манглинга (вспомни, с чего начался топик) нет. Только через С++ биндинги.
1) Не согласен с тем, что COM не позволяет напрямую использовать C++ для реализации интерфейсов. Контрпример — приведенный код, который будет успешно создавать экземпляр COM-интерфейса (AddRef()/Release() были опущены для краткости, с ними будет new CComObject<CSomething> вместо CSomething). И CComObject<> — это не "специфический биндинг для C++", а всего лишь shortcut для стандартных реализаций AddRef()/Release(), дополнительно упрощающий жизнь. Основной функционал — генерация vtable, выполняемая компилятором С++ без каких-либо дополнительных библиотек.
2) С тем, что "COM написан на C, так как там нет манглинга". Отсутствие манглинга и C-совместимые API для приложений означают extern "C" и желание разработчиков оставить совместимость для фанатов чистого C.

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

I>>>Открой ссылку для асиста, открой картинку что я показал, сравни и напиши сюда свое мнение
CC>>Дык существенная часть того что там он умеет для С++ попросту нафиг не нужно.

I>Отчасти это верно, потому что С++ уже вытеснен в дотаточно узкую нишу.
Твои фантазии касательно ниши С++ (и сопутствующий им флейм) оставим в стороне.

I>но по любому высокоуровневые оптимзации решают на порядки больше нежели числодробилки.
Это какое отношение имеет к обсуждению фич средств рефакторинга для С++?

I>Хочешь выделить небольшую фичу в отдельную подсистему — добро пожаловать в ад на с++.
Неоднократно делал. Ада не замечено. Видимо архитектурно изначально было всё в порядке.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

Да ты што!!

Нам решарпер любую архитектуру исправит. Это ведь такая продвинутая штука!

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

A>Во первых, нужно эффективно реализовать строку. Что я имею ввиду? Обычно строки используемые в таких случаях имеют маленькую длину. В таком случае можно применить слудующую оптимизацию: строка до определенного размера будет хранится не в динамической памяти, а в массиве фиксированной длины, являющимся членом класса строка.

В качестве лирического отступления.
При переходе с одной версии STL на другую, при неизменном компиляторе мы как то поимели неслабый провал производительности в парсере, который работал с std::string.
После разбора полётов оказалось, что виновата реализация std::string с буфером для маленьких строк. После "хака", убирающего буфер всё опять стало хорошо.

A>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.

Я уже представляю себе этот нереальный пипец в коде.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>>Неоднократно делал. Ада не замечено. Видимо архитектурно изначально было всё в порядке.
DC>Да ты што!!

Нам решарпер любую архитектуру исправит. Это ведь такая продвинутая штука!
На пришедшем от американских индусов C# проекте решарпер сжирал всю доступную память и вижуалка дохла в корчах.
Снёс нахрен и поставил ассист.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

I>Есть куча кода, который исправно работал где то с 2003го года, а сейчас появились новые требования для него.

I>Или такая задача — упрощения имеющегося кода.

И для этого мы, видимо, выделяем метод аж в целый класс

.

I>Можно, конечно, подойти по понЭрски — все переписать заново, с нуля или около того.

I>Но гораздо проще, быстре и надежнее будет сделать рефакторинг.

I>Практически везде нужно

I>1. выделение базового класса/интерфейса
I>2. перемещение методов по иерархии
I>3. использование базового класса

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

I>еще очень сильно не хватает "преобразование метода в класс"
I>и вообще очень много чего не хватает

I>при этом Решарпер предоставляет много средств которые не показыны в меню что я привел, например создание наследника, генерацию конструкторов и многое другое

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

I>заметь — выделение метода я упомянул только здесь.

CC>>Ты не меряй то, что надо для шарпа на плюсы.

I>Рефакторинг нужен независимо от языка.

I>В с++ мощные средства рефакторинга будут работать с такой же скоростью как и компилер

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

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

I>>Есть куча кода, который исправно работал где то с 2003го года, а сейчас появились новые требования для него.
I>>Или такая задача — упрощения имеющегося кода.

DC>И для этого мы, видимо, выделяем метод аж в целый класс

.

Упрощением может быть преобразование метода в класс, а может и наоборот, класса в метод.

I>>Можно, конечно, подойти по понЭрски — все переписать заново, с нуля или около того.

DC>

I>>Но гораздо проще, быстре и надежнее будет сделать рефакторинг.

I>>Практически везде нужно

I>>1. выделение базового класса/интерфейса
I>>2. перемещение методов по иерархии
I>>3. использование базового класса

DC>

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

свободные функции это каменный век.

DC>Я вообще придерживаюсь мнения, что biolerplate код должен убираться, а не плодиться с использованием мегакрутого решарпера.

он и убирается. при чем оставшийся код приводится к легко понятной форме

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

функции это круто. а как на счет подсистем над которыми работали десятки девелоперов в течении многих лет ?

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

I>>В с++ мощные средства рефакторинга будут работать с такой же скоростью как и компилер

потому ты их там и не видишь.
DC>Самое мощьное средство рефакторинга программист и если ему для написания кода нужна графическая штамповалка boilerplate кода, то либо что=то не так с языком, либо программист что-то не так делает.

Хорошему программисту лишний инструмент не помеха.

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

I>>но по любому высокоуровневые оптимзации решают на порядки больше нежели числодробилки.
CC>Это какое отношение имеет к обсуждению фич средств рефакторинга для С++?

Непосредственное.

I>>Хочешь выделить небольшую фичу в отдельную подсистему — добро пожаловать в ад на с++.
CC>Неоднократно делал. Ада не замечено. Видимо архитектурно изначально было всё в порядке.

"написание биндингов"

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

CC>Здравствуйте, Aleх, Вы писали:

A>>Например, такая простая ситуация. Есть GUI элемент Button. В процессе выполнения программы нам нужно передвинуть кнопку на форме.
A>>Положим, по координате X. С использованием Property это будет выглядеть так: button1.x = <новое значение>. Без button1.setX(<новое значение>).
CC>По мне так это абсолютно одно и то же. Синтаксический сахар и не более того.
CC>Я так понимаю проперти тебе там понадобилось для того, чтоб выполнить кроме самого изменения координаты еще и перерисовку (immediate или deferred, неважно).
CC>И тут и там вызов функции, только в случае с проперти он неявный. Что меня регулярно сильно раздражало при разборе индусокода на шарпе: эти уникумы любят пихать в сеттеры/геттеры дохренища кода, который делает много чего левого, не относящегося собственно к этой проперти.

A>>рассуждать в том же духе, что синтаксический сахар не нужен, можно оставаться программировать на ассемблере.
CC>проперти перед вызовом функции по мне так выигрывают совсем ничтожный мизер "синтаксического оверхеда" (С) (R) (ТМ), при этом иногда затрудняя читабельность кода, т.к. скрывают реальную работу, происходящую в этом месте. Как на глаз отличить присвоение проперти и присвоение переменной? Каждый раз лазить и смотреть есть ли сеттер?

Так чего тогда плюсовал слившему товарищу? Написал бы лучше рядом, что уродство — это не проперти, а "индусские" проперти. Блин, я ждал откровений, а все оказалось так банально. Подобная аргументация от чуваков, вовсю доказывающих, что в указателях прелестного С++ нет ничего сложного, способна только вызвать улыбку.

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

I>>>Windows Presentation Framework
V>>Ничего про нее не знаю.
I>Загляни в какой толковый туториал по MVVM.
Я тока поправлю. Все-таки не Framework, а Foundation. Windows Presentation Foundation

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

I>>>>Windows Presentation Framework
V>>>Ничего про нее не знаю.
I>>Загляни в какой толковый туториал по MVVM.
MK>Я тока поправлю. Все-таки не Framework, а Foundation. Windows Presentation Foundation

Да, я поторопился.

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

CC>Здравствуйте, Aleх, Вы писали:

A>>Например, такая простая ситуация. Есть GUI элемент Button. В процессе выполнения программы нам нужно передвинуть кнопку на форме.
A>>Положим, по координате X. С использованием Property это будет выглядеть так: button1.x = <новое значение>. Без button1.setX(<новое значение>).
CC>По мне так это абсолютно одно и то же. Синтаксический сахар и не более того.
CC>Я так понимаю проперти тебе там понадобилось для того, чтоб выполнить кроме самого изменения координаты еще и перерисовку (immediate или deferred, неважно).
CC>И тут и там вызов функции, только в случае с проперти он неявный. Что меня регулярно сильно раздражало при разборе индусокода на шарпе: эти уникумы любят пихать в сеттеры/геттеры дохренища кода, который делает много чего левого, не относящегося собственно к этой проперти.

A>>рассуждать в том же духе, что синтаксический сахар не нужен, можно оставаться программировать на ассемблере.
CC>проперти перед вызовом функции по мне так выигрывают совсем ничтожный мизер "синтаксического оверхеда" (С) (R) (ТМ), при этом иногда затрудняя читабельность кода, т.к. скрывают реальную работу, происходящую в этом месте. Как на глаз отличить присвоение проперти и присвоение переменной? Каждый раз лазить и смотреть есть ли сеттер?
Теоретически, среда разработки может подсказывать, что там происходит на самом деле. А вообще, в С++ много конструкций с неочевидной семантикой (использование перегруженных операторов). Многие поклонники Си говрят, что они по этой причине не переходят на С++. Если же грамотно использовать все эти фитчи, предоставляющие альтернативную семантику для привычных конструкций, проблемы не будет. Проблема в программистах недостаточно знающий язык или недостаточно хорошо умеющий проектировать интерфейсы классов.

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

CC>Здравствуйте, Aleх, Вы писали:

A>>Во первых, нужно эффективно реализовать строку. Что я имею ввиду? Обычно строки используемые в таких случаях имеют маленькую длину. В таком случае можно применить слудующую оптимизацию: строка до определенного размера будет хранится не в динамической памяти, а в массиве фиксированной длины, являющимся членом класса строка.

CC>В качестве лирического отступления.
CC>При переходе с одной версии STL на другую, при неизменном компиляторе мы как то поимели неслабый провал производительности в парсере, который работал с std::string.
CC>После разбора полётов оказалось, что виновата реализация std::string с буфером для маленьких строк. После "хака", убирающего буфер всё опять стало хорошо.
Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет. Тогда причем здесь это, я же описал совершенно другой случай.

A>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.

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

A>Например, такая простая ситуация. Есть GUI элемент Button. В процессе выполнения программы нам нужно передвинуть кнопку на форме. Положим, по координате X. С использованием Property это будет выглядеть так: button1.x = <новое значение>. Без button1.setX(<новое значение>).
В нормально спроектированной графической системе это будет выглядеть так:

button1.x = 30;
frame.redraw();

Автоматическая перерисовка — зло.

I>Есть такой класс как System.Windows.Forms.Control и его наследники. Куда деть тамошние проперти ?
Ты приводишь примеры какой-то незнакомой мне среды. Ты можешь показать УНИВЕРСАЛЬНЫЙ пример?
А ведь я тоже могу покахать тебе кусок на Мотиве и спросить, куда здесь засунуть проперти и зачем.

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

A>>>Во первых, нужно эффективно реализовать строку. Что я имею ввиду? Обычно строки используемые в таких случаях имеют маленькую длину. В таком случае можно применить слудующую оптимизацию: строка до определенного размера будет хранится не в динамической памяти, а в массиве фиксированной длины, являющимся членом класса строка.

CC>>В качестве лирического отступления.
CC>>При переходе с одной версии STL на другую, при неизменном компиляторе мы как то поимели неслабый провал производительности в парсере, который работал с std::string.
CC>>После разбора полётов оказалось, что виновата реализация std::string с буфером для маленьких строк. После "хака", убирающего буфер всё опять стало хорошо.

A>Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет.
Настраиваемый через шаблонный параметр размер буфера это цирк.
А если в одном месте программы идеальный буфер == 20 символов а потом строки передаются в код, где идеальный размер уже 50 что будет?

A>Тогда причем здесь это, я же описал совершенно другой случай.
Это всё к тому, что далеко не все "оптимизации" на практике ускоряют работу.
Причем работающая на конкретном проце оптимизация может ацки тормозить на другом.

A>>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

MK>Так чего тогда плюсовал слившему товарищу?
Ты о чём конкретно?

MK> Написал бы лучше рядом, что уродство — это не проперти, а "индусские" проперти.
Если ты ничего не понял то лучше бы спросил.

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

Ikemefula же ведёт разговор в русле: раз в тулах для С++ нет "средства инкапуляции филда в пропертю" то С++ есть говно недостойное.
На что следует резонный вопрос: а нахрена они нам сдались то, проперти в С++? Как то без них живём, проекты выпускаем, бабло получаем.

MK>Подобная аргументация от чуваков, вовсю доказывающих, что в указателях прелестного С++ нет ничего сложного, способна только вызвать улыбку.
Мьсе потрудится привести пруфлинк?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>Есть такой класс как System.Windows.Forms.Control и его наследники. Куда деть тамошние проперти ?
V>Ты приводишь примеры какой-то незнакомой мне среды. Ты можешь показать УНИВЕРСАЛЬНЫЙ пример?

Я привожу примеры из того, с чем работаю.
Из того, с чем не работаю, примеры не привожу.

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

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

MK>>Так чего тогда плюсовал слившему товарищу?
CC>Ты о чём конкретно?
О плюсе к этому посту.

MK>> Написал бы лучше рядом, что уродство — это не проперти, а "индусские" проперти.
CC>Если ты ничего не понял то лучше бы спросил.
Да вроде понятно.

CC>Уродство: это переться со своим уставом (методиками программирования на одном языке) в чужой монастырь (пытаться в тех же методиках писать на другом языке). И потом орать что это дескать не сам дурак, а язык плохой.
CC>Ей богу, шо дети.

CC>Ikemefula же ведёт разговор в русле: раз в тулах для С++ нет "средства инкапуляции филда в пропертю" то С++ есть говно недостойное.
CC>На что следует резонный вопрос: а нахрена они нам сдались то, проперти в С++? Как то без них живём, проекты выпускаем, бабло получаем.
Вот не надо. В твоем же примере убогости свойств, разговор идет про C#.

MK>>Подобная аргументация от чуваков, вовсю доказывающих, что в указателях прелестного С++ нет ничего сложного, способна только вызвать улыбку.
CC>Мьсе потрудится привести пруфлинк?
Нет, лопатить кучу страниц КСВ мне в лом. Но ты же не будешь отнекиваться, что всегда выступаешь на стороне С++.

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

I>Из того, с чем не работаю, примеры не привожу.
А с С++ ты работаешь?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>Из того, с чем не работаю, примеры не привожу.
CC>А с С++ ты работаешь?

Приходится посматривать туда.

Здравствуйте, dr.Chaos, Вы писали:
DC>графическая штамповалка boilerplate
Это все оттого, я считаю, что в C# мало средств метапрограммирования. Без макросов типичную конструкцию (свойство, например) разработчик языка не выпустит в виде библиотеки — надо в язык включать. А разработчик приложений не сможет генерацию и поддержку boilerplate поручить макросу — ему нужны будут тулзы.

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

MK>>>Так чего тогда плюсовал слившему товарищу?
CC>>Ты о чём конкретно?
MK>О плюсе к этому посту.

I>>>>Ну так в с++ нет такого понятия как интерфейсы, проперти, индексеры, эвенты и тд.
I>>>>Есть сущности аналогчные перечисленым, но на уровне инструментов они не поддерживаются, этот код ты лопатишь руками.
CC>>>Лопатишь это как то громко сказано. В языке всей этой ботвы нет. Этот функционал обеспечивается библиотеками.
I>>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.
V>Вот ты мне можешь объяснить, зачем нужен такой уродец, как property?

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

MK>>> Написал бы лучше рядом, что уродство — это не проперти, а "индусские" проперти.
CC>>Если ты ничего не понял то лучше бы спросил.
MK>Да вроде понятно.
Что то в глаза не бросается

CC>>Ikemefula же ведёт разговор в русле: раз в тулах для С++ нет "средства инкапуляции филда в пропертю" то С++ есть говно недостойное.
CC>>На что следует резонный вопрос: а нахрена они нам сдались то, проперти в С++? Как то без них живём, проекты выпускаем, бабло получаем.
MK>Вот не надо. В твоем же примере убогости свойств, разговор идет про C#.
Мсье не потрудился прочитать внимательно ветку сообщений?
См. выше процитированный кусок. Там чётко видно, что речь идёт о пропертях касательно С++.

MK>>>Подобная аргументация от чуваков, вовсю доказывающих, что в указателях прелестного С++ нет ничего сложного, способна только вызвать улыбку.
CC>>Мьсе потрудится привести пруфлинк?
MK>Нет, лопатить кучу страниц КСВ мне в лом. Но ты же не будешь отнекиваться, что всегда выступаешь на стороне С++.
Т.е. мьсе трепло?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>>Из того, с чем не работаю, примеры не привожу.
CC>>А с С++ ты работаешь?

I>Приходится посматривать туда.
А мы там давно работаем. В текущем проекте под 2008R2 используется С#, С и С++. C# исключительно для гуя.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>Здравствуйте, Aleх, Вы писали:

A>>>>Во первых, нужно эффективно реализовать строку. Что я имею ввиду? Обычно строки используемые в таких случаях имеют маленькую длину. В таком случае можно применить слудующую оптимизацию: строка до определенного размера будет хранится не в динамической памяти, а в массиве фиксированной длины, являющимся членом класса строка.

CC>>>В качестве лирического отступления.
CC>>>При переходе с одной версии STL на другую, при неизменном компиляторе мы как то поимели неслабый провал производительности в парсере, который работал с std::string.
CC>>>После разбора полётов оказалось, что виновата реализация std::string с буфером для маленьких строк. После "хака", убирающего буфер всё опять стало хорошо.

A>>Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет.
CC>Настраиваемый через шаблонный параметр размер буфера это цирк.
CC>А если в одном месте программы идеальный буфер == 20 символов а потом строки передаются в код, где идеальный размер уже 50 что будет?
Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов.
Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше.
A>>Тогда причем здесь это, я же описал совершенно другой случай.
CC>Это всё к тому, что далеко не все "оптимизации" на практике ускоряют работу.
CC>Причем работающая на конкретном проце оптимизация может ацки тормозить на другом.
Это если какие процы рассматривать? Как мне кажется, те оптимизации, которые на разных процах ведут себя по разному выполняет компилятор, но никак не программист.

A>>>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.

CC>>>Я уже представляю себе этот нереальный пипец в коде.
A>>В чем заключается этот пипец?
CC>В огромном шаблоне, в котором будет куча кода для реализации всех этих внутренних представлений.
Ну и что здесь плохого? Александреску, например, пропагандирует такой подход.

CC>Согласен с оратором, что оппоненту следует разъяснить, зачем проперти все таки так нужен в С++.
Причем без отсылки к шарповским библиотекам.

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

A>>>Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет.
CC>>Настраиваемый через шаблонный параметр размер буфера это цирк.
CC>>А если в одном месте программы идеальный буфер == 20 символов а потом строки передаются в код, где идеальный размер уже 50 что будет?

A>Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов.
A>Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше.

А не проще ли будет ускорить реально тормозящее место во всех реализациях строки — прикрутить к строке быстрый кастомный аллокатор?
Считай это подсказкой направления.

A>>>Тогда причем здесь это, я же описал совершенно другой случай.
CC>>Это всё к тому, что далеко не все "оптимизации" на практике ускоряют работу.
CC>>Причем работающая на конкретном проце оптимизация может ацки тормозить на другом.

A>Это если какие процы рассматривать? Как мне кажется, те оптимизации, которые на разных процах ведут себя по разному выполняет компилятор, но никак не программист.
Hint: дело не в командах проца а в работе кэша.

CC>>>>Я уже представляю себе этот нереальный пипец в коде.
A>>>В чем заключается этот пипец?
CC>>В огромном шаблоне, в котором будет куча кода для реализации всех этих внутренних представлений.
A>Ну и что здесь плохого? Александреску, например, пропагандирует такой подход.

Для людей, пишущих в стиле Александреску, на одном из моих предыдущих мест работы появился термин "укушенный Александреску".
Ибо человек, постигший Александреску-дзэн поначалу начинает писать на шаблонах всё. В прямом смысле, вообще всё.
А потом приходит пушистый северный зверёк в виде черепашьей скорости компиляции и (да, бывает и такое!) compiler limits.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>Здравствуйте, Aleх, Вы писали:

A>>>>Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет.
CC>>>Настраиваемый через шаблонный параметр размер буфера это цирк.
CC>>>А если в одном месте программы идеальный буфер == 20 символов а потом строки передаются в код, где идеальный размер уже 50 что будет?

A>>Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов.
A>>Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше.

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

A>>>>Тогда причем здесь это, я же описал совершенно другой случай.
CC>>>Это всё к тому, что далеко не все "оптимизации" на практике ускоряют работу.
CC>>>Причем работающая на конкретном проце оптимизация может ацки тормозить на другом.

A>>Это если какие процы рассматривать? Как мне кажется, те оптимизации, которые на разных процах ведут себя по разному выполняет компилятор, но никак не программист.
CC>Hint: дело не в командах проца а в работе кэша.
И что? кеш это часть процессора. и про команды я ничего не писал.

A>>Ну и что здесь плохого? Александреску, например, пропагандирует такой подход.
CC>Для людей, пишущих в стиле Александреску, на одном из моих предыдущих мест работы появился термин "укушенный Александреску".
CC>Ибо человек, постигший Александреску-дзэн поначалу начинает писать на шаблонах всё. В прямом смысле, вообще всё.
CC>А потом приходит пушистый северный зверёк в виде черепашьей скорости компиляции и (да, бывает и такое!) compiler limits.
Конечно, нужно знать меру, но вообще избегать шаблонов и особенно считать, что они не нужны совсем (как считают, например, оберонщики

) тоже не стоит.

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

CC>Т.е. мьсе трепло?
В таком тоне я общаться не собираюсь.

P.S. Пример

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

MC>Это все оттого, я считаю, что в C# мало средств метапрограммирования. Без макросов типичную конструкцию (свойство, например) разработчик языка не выпустит в виде библиотеки — надо в язык включать. А разработчик приложений не сможет генерацию и поддержку boilerplate поручить макросу — ему нужны будут тулзы.

Нет, это из-за распространённости языка

. На C# тоже можно писать лаконично, красиво и понятно, только миллионам леммингов надо быстро напедалить, вот и есть хорошие штамповалки, там где они нужны и востребованы. На С++ тоже востребованы, но сложны в изготовлении. Макросы безусловно вещь мощная, но их никто не даст использовать кому попало

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

CC> Согласен с оратором, что оппоненту следует разъяснить, зачем проперти все таки так нужен в С++.

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

avalon 1.0rc2 rev 272

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

CC>>Т.е. мьсе трепло?
MK>В таком тоне я общаться не собираюсь.
Аналогично. Потому и прошу подтверждать ссылками.

MK>P.S. Пример
Я право не вижу там ничего подобного "вовсю доказывающих, что в указателях прелестного С++ нет ничего сложного"
Единственная фраза, содержащая слово "указатель" вот:

Блин, такое ощущение что программирование на С++ ассоциируется с суровой рукопашной с указателями, копипастом кода и т.п.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

A>Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов.
A>Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше.
A>>>Тогда причем здесь это, я же описал совершенно другой случай.
Ничем он особо не лучше: от параметров шаблонов пухнет страшно код, да и засунуть 2 такие строки в один массив целая проблема. Т.е. Здесть возможно даже аллокатор стоит делать не параметром шаблона, а параметром конструктора.

A>>>>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.

A>Ну и что здесь плохого? Александреску, например, пропагандирует такой подход.

Скажем по другому: чем это лучше 5ти классов map, map_double_hashing и т.д. с одним интерфейсом? Допустим параметразовать можно было бы хеш функцией, но все эти 5 реализаций карты очень различаются и найти что-то общее в рамках одной реализации тут ИМХО будет сложнее, да и смысл?

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

B>>>Производительность не меньше? Какие тогда проблемы юзать язык в тех задачах, где от него есть польза, забив, труъ ли это ЯВУ? Или надо шашечки, а не ехать?
___>>Ехать. Но с комфортом.
B>Приведите пример задачи, которую нельзя "некриво" реализовать на С++ и я удивлю вас контрпримером

Да этими примерами забит весь КСВ. Оскомину уже набило.

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

I>>>>Из того, с чем не работаю, примеры не привожу.
CC>>>А с С++ ты работаешь?

I>>Приходится посматривать туда.
CC>А мы там давно работаем. В текущем проекте под 2008R2 используется С#, С и С++. C# исключительно для гуя.

Сколько месяцев этому проекту ?
сколько релизов было ?
Сколько тестеров, колько девелоперов ?
Сколько кастомизаций/варантов деплоймента ?
Сколько раз кастомер менял требования ?
Сколько есть конкурентов у продукта ?

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

I>>>Приходится посматривать туда.
CC>>А мы там давно работаем. В текущем проекте под 2008R2 используется С#, С и С++. C# исключительно для гуя.

I>Сколько месяцев этому проекту ?
I>сколько релизов было ?
I>Сколько тестеров, колько девелоперов ?
I>Сколько кастомизаций/варантов деплоймента ?
I>Сколько раз кастомер менял требования ?
I>Сколько есть конкурентов у продукта ?

Может тебе еще и номера счетов и пароли к SVN написать?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

TC>WTF, что это за язык?!

Это может быть любой язык, поддерживающий препроцессор

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

I>>Сколько месяцев этому проекту ?
I>>сколько релизов было ?
I>>Сколько тестеров, колько девелоперов ?
I>>Сколько кастомизаций/варантов деплоймента ?
I>>Сколько раз кастомер менял требования ?
I>>Сколько есть конкурентов у продукта ?

CC>Может тебе еще и номера счетов и пароли к SVN написать?

тяжелый случай. значит, зайдем с другой стороны,

объясни, почему рфакторинги, перечисленые в книге http://www.rsdn.ru/res/book/prog/rtp.xml
в главах 6-9 неактуальны для с++ воообще, а не только вашей песочницы

хочу услышать внятный ответ, как наприер:

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

Пока что все что сказал ты и dr.Chaos сводится к абурду следующего вида —
дай дураку перфоратор/шуроповерт, он всю стену враз опаскудит, посему для настоящих мастеров перфоратор/шуроповерт не нужен в прынцыпе.

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

I>объясни, почему рфакторинги, перечисленые в книге http://www.rsdn.ru/res/book/prog/rtp.xml
I>в главах 6-9 неактуальны для с++ воообще, а не только вашей песочницы
Ты б хоть ссылку давал не на содержание а на сам текст

Неужто ты хочешь сказать что в

I>хочу услышать внятный ответ
Только после того, как ответишь что из этого умеет решарпер:

Replace Constructors with Creation Methods[/*]

Move Creation Knowledge to Factory[/*]

Encapsulate Classes with Factory[/*]

Introduce Polymorphic Creation with Factory Method[/*]

Encapsulate Composite with Builder[/*]

Inline Singleton[/*]

ComposeMethod[/*]

Replace Conditional Logic with Strategy[/*]

Move Embellishment to Decorator[/*]

Replace State-Altering Conditionals with State[/*]

Replace Implicit Tree with Composite[/*]

Replace Conditional Dispatcher with Command[/*]

Form Template Method[/*]

ExtractComposite[/*]

Replace One/Many Distinctions with Composite[/*]

Replace Hard-Coded Notifications with Observer[/*]

Unify Interfaces withAdapter[/*]

Extract Adapter[/*]

Replace Implicit Language with Interpreter [/*]

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

B>Это может быть любой язык, поддерживающий препроцессор

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

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

I>>хочу услышать внятный ответ
CC>Только после того, как ответишь что из этого умеет решарпер:

Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.

Но раз уж ты таки считаешь, что нобходимость рефакторинга в с++ зависит от решарпера,

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

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

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

I>>>хочу услышать внятный ответ
CC>>Только после того, как ответишь что из этого умеет решарпер:

I>Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.
Зависят. Ты тут речь завёл с того, что С++ дескать такое говно что под него нет тулов для рефакторинга.

I>>>Парсить С++ код та еще задача. до сих пор нет нормального средства рефакторинга, которое было бы таким же доступным как и то что есть в решарпере

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

I>в готовом виде он конечно все это он не умеет
Тогда какое отношение эта книга имеет к разговору о тулах для рефакторинга?

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

I>Соответсвенно, хочу услышать внятный вопрос — нужны ли рефакторинги _тобою_ перечисленные в С++.
Это не мною перечисленные. Это "рфакторинги, перечисленые в книге в главах 6-9" из твоего поста.

I>Т.е. да или нет, без виляний в твоем духе.
Прекращай нести чушь.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, abdul.zycor, Вы писали:
AZ> ... В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста

.

Да я бы не стал никогда писать на чистом си или сипипи. Если мне не надо конструктора в объекте я объявлю струтуру, нужен конструктор объявлю класс. Нет смысла все функции прятать в методы. Нет смысла обявлять все переменные в начале блока, как в си, а есть смысл объявлять по мере необходимости. В общем чистота программы в плане написания на си или на сипипи ненужна.

++равствуйте, CreatorCray, Вы писали:

I>>Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.
CC>Зависят.

Перечитай выделеное чуть выше. Не понял идею, каким образом необходимость конкретного рефакторинга для С++ зависит от решарпера ? Начни так "в нативном с++ рефакторинг ... не нужен, потому что решарпер в .Net ..."

CC>На что тебе был приведён тул — ассист.

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

CC>Ты начал ныть что мол, он слишком мало умеет.

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

CC>На что тебе было сказано что для рефакторинга в С++ он умеет достаточно.

Был даден список рефакторингов, ты так и не ответил на вопрос, почему эти рефакторинги нахрен не нужны в с++

Ты так и не не отвтил на этот вопрос, а начал валять дурака

>хочу услышать внятный ответ
Только после того, как ответишь что из этого умеет решарпер:

— ответа, заметь, не было

I>>в готовом виде он конечно все это он не умеет
CC>Тогда какое отношение эта книга имеет к разговору о тулах для рефакторинга?

чуть ниже было пояснение или для тебя абзац текта слишком сложно осилить ?

I>>но все до единого эти рефакторнги делаются из более простых, например выделение подкласса, интерфейса, движение метода, преобразование конструктора в фабричный метод и тд.
CC>Простые рефакторинги для методик разработки, принятых и используемых в С++ в ассисте есть.

Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?

В чем особенность этого С++, что в нём не надо упрощать логику ? Что за мега-методики ?

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

I>>Соответсвенно, хочу услышать внятный вопрос — нужны ли рефакторинги _тобою_ перечисленные в С++.
CC>Это не мною перечисленные. Это "рфакторинги, перечисленые в книге в главах 6-9" из твоего поста.

Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?

I>>Т.е. да или нет, без виляний в твоем духе.
CC>Прекращай нести чушь.

Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?

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

допустим, если взять вместо С++ Эйфель, то худо-бедно можно cогласиться, что Эйфель вынуждает соблюдать принцип замещения Лисков.

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

P.S. слушай, тебе AV не помогает постить ? А то ощущение у вас одна и та же болезнь. Ты хоть пересядь куда.

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

S>Да я бы не стал никогда писать на чистом си или сипипи. Если мне не надо конструктора в объекте я объявлю струтуру, нужен конструктор объявлю класс. Нет смысла все функции прятать в методы. Нет смысла обявлять все переменные в начале блока, как в си, а есть смысл объявлять по мере необходимости. В общем чистота программы в плане написания на си или на сипипи ненужна.
компилятор или coding guidelines вполне может иметь своё мнение по этому вопросу. позови посмотреть когда будешь доказывать им свою точку зрения.

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

S>Нет смысла обявлять все переменные в начале блока, как в си, а есть смысл объявлять по мере необходимости.

Ты точно ничего не путаешь? Кто сказал, что в си нужно объявлять переменные только в начале блока?

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

I>>>Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.
CC>>Зависят.
I>Перечитай выделеное чуть выше. Не понял идею, каким образом необходимость конкретного рефакторинга для С++ зависит от решарпера ? Начни так "в нативном с++ рефакторинг ... не нужен, потому что решарпер в .Net ..."
Не дури голову. Прочитай ветку с начала обсуждения ассиста как средства рефакторинга для С++.

CC>>На что тебе было сказано что для рефакторинга в С++ он умеет достаточно.
I>Был даден список рефакторингов, ты так и не ответил на вопрос, почему эти рефакторинги нахрен не нужны в с++
Потому что вопрос тролльский и к теме отношения не имеет.

I>- ответа, заметь, не было
Твоего в общем то тоже. Или ответом было "ничего не умеет"?

I>>>но все до единого эти рефакторнги делаются из более простых, например выделение подкласса, интерфейса, движение метода, преобразование конструктора в фабричный метод и тд.
CC>>Простые рефакторинги для методик разработки, принятых и используемых в С++ в ассисте есть.

I>Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?
Так. Ясно. Чукча у нас даже не читатель.
Пруфлинк на мои слова где я утверждаю что "рефакторинги, приведеные в книге, не нужны в С++".
Озаботься напоминанием себе о чём все таки идёт речь в этой ветке.

I>>>Соответсвенно, хочу услышать внятный вопрос — нужны ли рефакторинги _тобою_ перечисленные в С++.
CC>>Это не мною перечисленные. Это "рфакторинги, перечисленые в книге в главах 6-9" из твоего поста.
I>Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?
А с чего ты взял вдруг что они не нужны? Я ничего подобного не утверждал.
Не нужно свои фантазии приписывать другим.
Или это такой новый метод троллинга?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

В С# и Java кроме классов ничего долгое время и не было

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

I>>Перечитай выделеное чуть выше. Не понял идею, каким образом необходимость конкретного рефакторинга для С++ зависит от решарпера ? Начни так "в нативном с++ рефакторинг ... не нужен, потому что решарпер в .Net ..."
CC>Не дури голову. Прочитай ветку с начала обсуждения ассиста как средства рефакторинга для С++.

I>Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.
Зависят.

Твоей ответ чисто в КУ

I>>Был даден список рефакторингов, ты так и не ответил на вопрос, почему эти рефакторинги нахрен не нужны в с++
CC>Потому что вопрос тролльский и к теме отношения не имеет.

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

I>Нужны высокоуровневые средтва, рефакторинг тот же.
Зачем?
Объясни?
Какие средства надо? Что у тя входит в рефакторинг?
Ты не меряй то, что надо для шарпа на плюсы.

Это не троллинг — это принуждение к ответу.

Или вот

I>хочу услышать внятный ответ
Только после того, как ответишь что из этого умеет решарпер:

И снова ответа нет

I>>- ответа, заметь, не было
CC>Твоего в общем то тоже. Или ответом было "ничего не умеет"?

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

и вот эти рефакторинги решарпер уже умеет, а ассист — нет.

выделеное и три строчки понятны или нет ?

Стало быть вопрос — нужны ли рефакторинги из книги при разработке на С++ или нет.

В который раз задаю вопрос !

I>>Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?
CC>Так. Ясно. Чукча у нас даже не читатель.
CC>Пруфлинк на мои слова где я утверждаю что "рефакторинги, приведеные в книге, не нужны в С++".

I>Нужны высокоуровневые средтва, рефакторинг тот же.
Зачем?
Объясни?
Какие средства надо? Что у тя входит в рефакторинг?
Ты не меряй то, что надо для шарпа на плюсы.

как трактовать твой недо-ответ я и не знаю.

I>>Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?
CC>А с чего ты взял вдруг что они не нужны? Я ничего подобного не утверждал.

ты вообще ничего не утверждал и утверждал одновременно

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

Нужны или не нужны рефакторинги из книги ты не сказал.

Вот что было

I>Нужны высокоуровневые средтва, рефакторинг тот же.
Зачем?
Объясни?
Какие средства надо? Что у тя входит в рефакторинг?
Ты не меряй то, что надо для шарпа на плюсы.

Хочу услышать ответ примерно такой по форме:

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

или

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

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

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

DC>В С# и Java кроме классов ничего долгое время и не было

Это значит, что для них и инструментов надо меньше. Например для С# и Джавы не нужны инструменты рефакторинга множественного наследования или рефакторнга макросов.

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

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

I>Это значит, что для них и инструментов надо меньше. Например для С# и Джавы не нужны инструменты рефакторинга множественного наследования или рефакторнга макросов.

I>А получается наоборот — классы есть и в С++ а инструмента для их рефакторинга нет, даже самого простого.

В lisp-е тоже есть классы, а средств для рефакторинга нету

. Просто вселенский заговор какой-то.

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

I>>Это значит, что для них и инструментов надо меньше. Например для С# и Джавы не нужны инструменты рефакторинга множественного наследования или рефакторнга макросов.

I>>А получается наоборот — классы есть и в С++ а инструмента для их рефакторинга нет, даже самого простого.

DC>В lisp-е тоже есть классы, а средств для рефакторинга нету

. Просто вселенский заговор какой-то.

И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?

Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?

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

I>И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?

I>Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?

А какое это имеет отношение к рефакторингам Кириевски? Кириевски написал — все должны делать. ёпт!

Вот и выросло поколение...

avalon 1.0rc2 rev 300, zlib 1.2.3
build date: 19.08.2009 14:13:36 MSD +04:00
Qt 4.5.2

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

I>>И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?

I>>Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?

DC>А какое это имеет отношение к рефакторингам Кириевски? Кириевски написал — все должны делать. ёпт!

На вопросы для начала ответь.

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

нет никаких рефакторингов Кериевски, в его книги приведены самые общие рефакторинги, которые нужны везде где есть классы например.

В лиспе тоже есть классы, представь себе.

Здравствуйте, Ikemefula, Вы писали:
I>И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?
Лисп прекрасно живет и развивается в своем комьюнити. И будет так же жить и развиваться в ближайшие 50 лет. А вот судьба нынешнего мейнстрима предрешена: c#,java ждет судьба кобола, питон — в самом лучшем случае судьба tcl.

I>Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?
Набрали команду инди-кодеров, продолбали все полиме^W акции и превратились в моральных пигмеев?

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

I>>И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?
MC>Лисп прекрасно живет и развивается в своем комьюнити. И будет так же жить и развиваться в ближайшие 50 лет. А вот судьба нынешнего мейнстрима предрешена: c#,java ждет судьба кобола, питон — в самом лучшем случае судьба tcl.

Пусть развивается. Он за пределами стат-погршности, всего то.

Нужен интрумент для решения текущих задач бизнеса, а Лисп — нет, не нужен.

I>>Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?
MC>Набрали команду инди-кодеров, продолбали все полиме^W акции и превратились в моральных пигмеев?

Нет, они нашли инструмент, который решил их задачи.

V>>Вызов по COM — это реальный вызов метода, in-proc или out-proc. В результате имеет счетчик ссылок и прочее.
C>А каким образом происходит вызов out-of-proc методов?
C>Hint: там ещё посылается оконное сообщение.

Вызов out-proc это вызов RPC. C 96-го года (Windows NT), в качестве транспорта, оконные сообщения не используются. В Windows 2k, XP и 2k3 передача основной массы данных осуществляется взаимодействием через LPC-порты. К сожалению, они синхронные, поэтому, что бы поддержать общий интерфейс асинхронных вызовов используются отсылка сообщений. Т.е. сообщения используются в качестве уведомлений.

Теперь посмотрим на Windows Vista и старше. Тут дела еще лучше — ALPC порты. В нашем контексте их основное новшество — возможность привязки IOCP (I/O Completion Ports), полностью асинхронный интерфейс и передача контекстов, в рамках одного transceiv'а. Это позволило полностью отказаться от оконных сообщений (я их там не видел, поправьте, если кто-то раскопал).

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

DC>Здравствуйте, Aleх, Вы писали:

A>>Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов.
A>>Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше.
A>>>>Тогда причем здесь это, я же описал совершенно другой случай.
DC>Ничем он особо не лучше: от параметров шаблонов пухнет страшно код, да и засунуть 2 такие строки в один массив целая проблема. Т.е. Здесть возможно даже аллокатор стоит делать не параметром шаблона, а параметром конструктора.
Можно и так, только если без параметра шаблона, в теории будет медленнее.

A>>>>>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.

A>>Ну и что здесь плохого? Александреску, например, пропагандирует такой подход.

DC>Скажем по другому: чем это лучше 5ти классов map, map_double_hashing и т.д. с одним интерфейсом? Допустим параметразовать можно было бы хеш функцией, но все эти 5 реализаций карты очень различаются и найти что-то общее в рамках одной реализации тут ИМХО будет сложнее, да и смысл?
Различаться будут только реализацией. Ну а смысл в том, чтобы сократить объем кода библиотеки: предполагается, что эти же внутренние представления можно задействовать для других контейнеров — например, set.

Здравствуйте, Eugeny__, Вы писали:
E__>Ты точно ничего не путаешь? Кто сказал, что в си нужно объявлять переменные только в начале блока?
Эээ... как бы да, если быть точнее после того как хотя бы одна переменная была использована, объявлять переменные нельзя (это касается Си).

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

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

S>>Да я бы не стал никогда писать на чистом си ...
A>компилятор или coding guidelines вполне может иметь своё мнение по этому вопросу. позови посмотреть когда будешь доказывать им свою точку зрения.

Компилятор со мной уже согласен, coding guidelines — это не ко мне

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

S>>>Да я бы не стал никогда писать на чистом си ...
A>>компилятор или coding guidelines вполне может иметь своё мнение по этому вопросу. позови посмотреть когда будешь доказывать им свою точку зрения.
S>Компилятор со мной уже согласен,
компилятор С++. компилятор С не согласится с, хотя бы, class. По крайней мере, я таких не знаю (#define class struct не считается). то есть пишешь ты на С++, и упоминать С всуе совсем незачем было. просто бы сказал, что в споре C vs С++ ты за C++.

S>coding guidelines — это не ко мне

вот и индусы так говорят, и, что хуже, делают

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

S>Нет смысла обявлять все переменные в начале блока, как в си, а есть смысл объявлять по мере необходимости.

#pragma flame on
переменные вообще не нужны

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

E__>>Ты точно ничего не путаешь? Кто сказал, что в си нужно объявлять переменные только в начале блока?
S>Эээ... как бы да, если быть точнее после того как хотя бы одна переменная была использована, объявлять переменные нельзя (это касается Си).
в C99 стало можно объявлять не только в начале блока.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E__>>>Ты точно ничего не путаешь? Кто сказал, что в си нужно объявлять переменные только в начале блока?
S>>Эээ... как бы да, если быть точнее после того как хотя бы одна переменная была использована, объявлять переменные нельзя (это касается Си).
CC>в C99 стало можно объявлять не только в начале блока.
мне что-то кажется, что у него компилятор С99 не очень поддерживает

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

MC>>Лисп прекрасно живет и развивается в своем комьюнити. И будет так же жить и развиваться в ближайшие 50 лет. [...]

I>Пусть развивается. Он за пределами стат-погршности, всего то.

I>Нужен интрумент для решения текущих задач бизнеса, а Лисп — нет, не нужен.

Так сказал Ikemefula!

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

B>>Это может быть любой язык, поддерживающий препроцессор

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

гугл

http://vcc.codeplex.com/wikipage?title=Memory%20Reinterpretation

VCC is a tool that proves correctness of annotated concurrent C programs or finds problems in them. VCC extends C with design by contract features, like pre- and postcondition as well as type invariants.

Здравствуйте, Ikemefula, Вы писали:
I>Нужен интрумент для решения текущих задач бизнеса
У всех разные задачи и, соответственно, применяются разные инструменты их решения. Где-то нужна профессиональная команда и высокотехнологичные средства разработки, навроде лиспа. А чтобы торговать контентом почтовых ящиков клиентов — и программировать-то ничего не надо. Jedem das Seine.

+1.

C — живее всех живых.

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

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

Сдается мне, товарищ еще ни разу не нарывался на функции в пару-тройку тысяч строк и без локальных переменных

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

I>>Нужен интрумент для решения текущих задач бизнеса
MC>У всех разные задачи и, соответственно, применяются разные инструменты их решения. Где-то нужна профессиональная команда и высокотехнологичные средства разработки, навроде лиспа.

Ну да, есть проектов, меньше статпогрешности

Здравствуйте, Ikemefula, Вы писали:
I>Ну да, есть проектов, меньше статпогрешности
Извини, я не смог уловить смысла этого высказывания.

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

MC>Извини, я не смог уловить смысла этого высказывания.
Он довольно часто выражается в стиле Черномырдина

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

V>

V>button1.x = 30;
V>frame.redraw();
V>

V>Автоматическая перерисовка — зло.
Это еще почему? Зло оно только в случае классической виндовой архитектуры и библиотек, так как может хреново выглядеть из-за частых перерисовок. В WPF все иначе, и это реально удобнее.

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

IID>>Тем не менее это не мешает "мясо" библиотеки писать на С++, а наружу выставлять pure-С API. Вон, в винде дофига юзерленда именно так сделано.
V>Ну это кривизна необыкновенная. Когда два С++ класса общаются между собой на C, и лишены возможностей взимодействовать с использованием возможностей С++. И то, как это сделано в ВинАПИ, кстати, есть тоже кривулина.
+1. Причем не понятно, почему сторонники С# так "любят" спорить о пропертях, как по мне, херня на постном масле, полезная в C#, но не особо ненужная в С++, а вот отсутствие стандартизированной модульности в С++ на уровне бинарных модулей, вот это реальный минус С++.

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

I>>Ну да, есть проектов, меньше статпогрешности
MC>Извини, я не смог уловить смысла этого высказывания.

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

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

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

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

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

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

I>>>>>Я не сильно слежу за ассистом. он умеет ли он (2005я)
CC>>>>Не могу представить когда в C++ может понадобиться аналог пункта "Convert"

I>>>Ну так в с++ нет такого понятия как интерфейсы, проперти, индексеры, эвенты и тд.
I>>>Есть сущности аналогчные перечисленым, но на уровне инструментов они не поддерживаются, этот код ты лопатишь руками.
CC>>Лопатишь это как то громко сказано. В языке всей этой ботвы нет. Этот функционал обеспечивается библиотеками.

I>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.
Это в С++ сделать возможно, а вот ты приведи код который позволяет в компайлтайме узнатьсуществование филды/метода у класса ивыбрать дальнейший алгоритм компиляции.

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

S>Здравствуйте, abdul.zycor, Вы писали:
AZ>> ... В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста

.
S>Да я бы не стал никогда писать на чистом си или сипипи. Если мне не надо конструктора в объекте я объявлю струтуру, нужен конструктор объявлю класс. Нет смысла все функции прятать в методы. Нет смысла обявлять все переменные в начале блока, как в си, а есть смысл объявлять по мере необходимости. В общем чистота программы в плане написания на си или на сипипи ненужна.

Святая простота..

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

I>>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.
O> Это в С++ сделать возможно,

Ты код покажи, желательно, что бы строчек было поменьше.

O>а вот ты приведи код который позволяет в компайлтайме узнать существование филды/метода у класса ивыбрать дальнейший алгоритм компиляции.

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

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

I>>Есть в с++ нечто, что рождает монстров вроде буста и стл, и благодаря им так и сложилось с серверами.

F>На самом деле ни буст ни стл не являются необходимым условием написания программ, даже таких хитрых, как промышленный веб-сервер. Ни что не мешает с нуля сделать свои библиотеки с преферансом и гетерами — так как это обычно делают на голом С, типичный пример apache и его apr + apr-util.

F>Ну, если учесть, что компилятор, который нормально умеет компилировать под разные платформы всего один, и он один и тот же для c и c++

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

F>Имхо никакой разницы нет — поддержка этих языков практически одинакова.

F>Опять-таки ситуация с С и С++ в этом плане практически одинакова. И она не является препятствием для написания серверов

Просто подумай, почему STL начала широко применяться практически сразу после выхода первых версий. Без наличия пространной документации.
Что такое изучение ворнингов компилятора на vc 4.2 например? — ну п... полный!
Что этих мышей заставляло и заставляет плакать и колоться???

Я бы разделил программистов на 2 группы:
первая — уже поняли, что STL (и boost, и ему подобные расширения) не имеют альтернативы в других языках
вторая — мне их жалко...

Конкретный пример из личной практики.
Крайне глючная DLL (примерно 50000 строк гавнокода, писалась 1.5 года, все ошибки "плавающие", в debug не воспроизводятся) "на чистом C" переписана на 70% функционала примерно за 2 недели. Причем практически "на автомате", без мучительных усилий. Прошел год — еще не видел ни одной ошибки (при отлаженной системе транспортировки багов). Ах, да. Был ли "рефакторинг". Из старых исходников актуальны были примерно 1-2% кода, остальное сделано просто по описанию функционала.

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

B>Здравствуйте, abdul.zycor, Вы писали:

AZ>>В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста

.
B>C++ позволяет сильно автоматизировать и упрощать многие вещи (та же работа со строками или STL). Это не означает, что на C++ нельзя написать код, идентичный по производительности коду на C и при этом занимающий в 2 раза меньше строк. Но означает, что для того, чтобы написать громоздкое приложение на C надо писать много кода, на C++ для этого достаточно пару раз не задуматься о последствиях и поюзать стандартные конструкции кривым способом.

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

B>Например, хэш-таблицу для повторяющихся строк на C можно реализовать, вручную распихав строки в едином блоке без дублирования совпадающих подстрок и сделав вычисление хэшей. Займет это N строк. На C++ все можно реализовать аналогично низкоуровнево, займет это меньше N строк и будет иметь красивую модульную структуру. НО всегда найдется программист, который поюзает std::map<std::string, std::string>, не вьезжая в принцип его работы, чем увеличит требуемый размер памяти в разы.

Претензии к map или string? К памяти? Вообще там не въезжая можно породить с десяток решений под разные требования (и все не "кривые").
Насколько я в курсе, std::map<std::string, std::string> хотя бы работает. Если тот же автор то же самое ручками писать начнет. Ой-ой.
Просто не раз видел, какой бред можно написать, например вместо sort -> unique.
Вплоть до создания временных таблиц на SQL и выполнения каких-то мутных select. С полным утоплением в г... всех зависимостей, т.е. при изменении требований вообще неясно где копать.

B>На практике получается, что объяснить программистам, как писать компактный и производительный код на С++ сложнее, чем запретить им пользоваться чем-либо кроме C. Увы.

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

Не-а. Он будет руками махать вместо самолета.

AZ>Всем привет! Не так давно стал изучать программирование для unix систем.

c++ не очень надёжный язык, не собрано достаточно статистики,
имеет некоторые неявные нюансы на этапе разработки.

системы реального времени и бортовые системы пишут в основном на c.
марсоходы, которые >3 лет ездили по марсу
собраны на powerpc 120 и осрв vxworks (язык c),
ядро vxworks имеет статистику более 30 лет
и поэтому считается наиболее отказоустойчивой осрв

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

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

BB>>Здравствуйте, abdul.zycor, Вы писали:

AZ>>>Какие могут быть обьяснения тому?

BB>>http://www.kernel.org/pub/linux/docs/lkml/#s15-3
B>[quote]There is no point in just compiling the kernel with g++ and writing the odd function in C++, this would just result in a confusing mix of C and C++ code. Either the kernel is left in C, or it's all moved to C++.[/quote]
B>Ну это просто зашибись аргумент. Типа, или всё бросить и начать сначала, или ничего не трогать и закрыть глаза на удобные фичи C++. Ну типа нах нам автоматическая коробка, ведь это надо все машины с ручной в утиль сдать, а потом выпускать на улицы автомат. А то чтобы по одной улице одни ездили на "ручке", а другие на "автомате" — это же некошерно. Да и Торвальдс не разрешит.
B>О том, как бы поюзать часть удобных фич C++, дабы быстрее и качественнее решить проблемы, стоящие перед разработчиками сейчас, никто и не задумывается. Элементарно можно создать inline wrapper-ы на С++ вокруг существующего API на C — вызывать будет удобнее (те же mutex guard-ы можно красиво реализовать), размер бинаря не увеличит, ибо все разрезолвится во время компиляции. Ту же VFS сделать на базе виртуальных функций, чтобы унаследовал класс, переопределил 3 метода, вернул new MyClass(); из entry point — и VFS юзабельна. Но ведь нет — куда кошернее руками заполнять таблицы указателей и кастить inode->extension к struct my_vfs_driver_extension в каждом вызове...

Это все фигня. Реальный аргумент один. В том же тексте ниже, курсивом:

the whole C++ exception handling thing is fundamentally broken . It's _especially_ broken for kernels.

Ядро НЕ ПИШУТ на С++. Потому что в принципе исключения не могут правильно работать в режиме ядра.
Точнее, на уровне ядра их поддержка и реализована, как относительно "высокоуровневый" сервис, на С + ассемблер.

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

AZ>>Всем привет! Не так давно стал изучать программирование для unix систем.

T>c++ не очень надёжный язык, не собрано достаточно статистики,
T>имеет некоторые неявные нюансы на этапе разработки.

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

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

HA>Я бы разделил программистов на 2 группы:
HA>первая — уже поняли, что STL (и boost, и ему подобные расширения) не имеют альтернативы в других языках
HA>вторая — мне их жалко...

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

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

HA>>Я бы разделил программистов на 2 группы:
HA>>первая — уже поняли, что STL (и boost, и ему подобные расширения) не имеют альтернативы в других языках
HA>>вторая — мне их жалко...

I>Чуток наоборот, первая — это челы понимают, что без stl или boost за другими языками не угнаться даже при правильном ветре.
А вторая ни за кем не гонится и спокойно делает и сдаёт проекты.
Первым нужны "шашечки", вторым — "ехать".

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

T>ядро vxworks имеет статистику более 30 лет
T>и поэтому считается наиболее отказоустойчивой осрв

Не, ну если у вас есть унаследованный код 30-летней давности, то точно лучше ничего не менять, пока работает

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

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

I>Чуток наоборот, первая — это челы понимают, что без stl или boost за другими языками не угнаться даже при правильном ветре.

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

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

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

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

Сейчас например найти чела, который умеет шаблоны С++ на уровне достаточном для буст или хотя бы стл крайне сложно.

Еще лет 5 назад было гораздо проще.

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

I>Мощь есть, это так. Только что бы эта мощь не задавила программиста, надо вагон времени убить, года три, не меньше.

То есть?

I>Сейчас например найти чела, который умеет шаблоны С++ на уровне достаточном для буст или хотя бы стл крайне сложно.

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

I>Еще лет 5 назад было гораздо проще.

Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?

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

ГВ>Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?

Узнают о boost, когда уже нет времени учиться.
Время обучения потрачено непонятно на что.
Нет знания ни ОС, ни основ теории, ни хотя бы одного языка на профессиональном уровне.
С таким багажом про boost лучше ничего не знать.

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

ГВ>>Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?

HA>Узнают о boost, когда уже нет времени учиться.

Это как это? До пенсии всего ничего, что ли?

HA>Время обучения потрачено непонятно на что.

Время обучения чему?

HA>Нет знания ни ОС, ни основ теории, ни хотя бы одного языка на профессиональном уровне.
HA>С таким багажом про boost лучше ничего не знать.

Что-то я тебя не понимаю.

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

I>>Мощь есть, это так. Только что бы эта мощь не задавила программиста, надо вагон времени убить, года три, не меньше.

ГВ>То есть?

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

I>>Сейчас например найти чела, который умеет шаблоны С++ на уровне достаточном для буст или хотя бы стл крайне сложно.

ГВ>Не понял. На уровне, достаточном для того, чтобы написать буст, или чтобы использовать буст?

Использовать.

I>>Еще лет 5 назад было гораздо проще.

ГВ>Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?

За 5 лет С++ подрястерял позиции, а студенты в основном джавой и дотнетом интересуются.

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

ГВ>>>Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?

HA>>Узнают о boost, когда уже нет времени учиться.

ГВ>Это как это? До пенсии всего ничего, что ли?

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

HA>>Время обучения потрачено непонятно на что.

ГВ>Время обучения чему?

Время обучения в университете. Бусту там не учат.

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

ГВ>>>>Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?

HA>>>Узнают о boost, когда уже нет времени учиться.
ГВ>>Это как это? До пенсии всего ничего, что ли?
I>Бусту надо учиться, а в дотнет и джаву можно идти буквально сразу.

Хм. Это для меня новость, вообще-то. Бусту надо учиться никак не более, чем надо учиться практическому программированию на C++. Он, собственно, для того и предназначен — для решения вполне определённых задач.

С другой стороны — да, приличный C++-ник получается, где-то, не меньше, чем за год. В прочем, с другими языками примерно то же самое.

HA>>>Время обучения потрачено непонятно на что.
ГВ>>Время обучения чему?
I>Время обучения в университете. Бусту там не учат.

А... Понятно. Опять университет виноват?

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

I>>>Мощь есть, это так. Только что бы эта мощь не задавила программиста, надо вагон времени убить, года три, не меньше.
ГВ>>То есть?
I>То есть входная планка для буста гораздо выше, чем для дотнета или джавы.

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

I>>>Сейчас например найти чела, который умеет шаблоны С++ на уровне достаточном для буст или хотя бы стл крайне сложно.
ГВ>>Не понял. На уровне, достаточном для того, чтобы написать буст, или чтобы использовать буст?
I>Использовать.

I>>>Еще лет 5 назад было гораздо проще.
ГВ>>Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?

I>За 5 лет С++ подрястерял позиции, а студенты в основном джавой и дотнетом интересуются.

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

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

ГВ>Не понял. На что нужно потратить три года? На буст? Чепуха. На C++? Тоже преувеличение — года вполне достаточно, а базовый язык вообще осваивается за несколько месяцев. Чему нужно три года учиться?

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

Вероятно ты со студентами и выпускниками дела не имеешь.

ГВ>>>Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?

I>>За 5 лет С++ подрястерял позиции, а студенты в основном джавой и дотнетом интересуются.

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

Гиперсложности не нужно. Достаточно, что бы на рынке был продукт попроще, доступнее, прозрачнее при сравнимых возможностях.

Раньше например джава была но люди интересовались с++. У нас например чуть не весь поток такой был.

С++ сам по себе геморрой, а буст достаточно сложен для начинающего.

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

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

HA>>>>Узнают о boost, когда уже нет времени учиться.
ГВ>>>Это как это? До пенсии всего ничего, что ли?
вообще надо жить как-то, чтобы деньги платили.

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

ГВ>Хм. Это для меня новость, вообще-то. Бусту надо учиться никак не более, чем надо учиться практическому программированию на C++. Он, собственно, для того и предназначен — для решения вполне определённых задач.
и вообще это просто набор библиотек в стиле "бери и пользуйся". тем не менее, вещи вроде mpl или concept check доходят далеко не сразу. Или просто не доходят никогда.

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

HA>>>>>Узнают о boost, когда уже нет времени учиться.
ГВ>>>>Это как это? До пенсии всего ничего, что ли?
HA>вообще надо жить как-то, чтобы деньги платили.

Ну, с этим, конечно, не поспоришь.

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

Вот это как раз для меня один из самых больших парадоксов IT-отрасли. Казалось бы, навыки именно программирования нужны примерно одни и те же, что для Java, что для .Net, что для C++. Они сразу не появляются, каким бы простым язык ни был. Но нет — почему то считается, что на "простом" языке можно писать любому неучу.

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

ГВ>>Хм. Это для меня новость, вообще-то. Бусту надо учиться никак не более, чем надо учиться практическому программированию на C++. Он, собственно, для того и предназначен — для решения вполне определённых задач.
HA>и вообще это просто набор библиотек в стиле "бери и пользуйся". тем не менее, вещи вроде mpl или concept check доходят далеко не сразу. Или просто не доходят никогда.

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

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

ГВ>Вот это как раз для меня один из самых больших парадоксов IT-отрасли. Казалось бы, навыки именно программирования нужны примерно одни и те же, что для Java, что для .Net, что для C++.

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

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

>Они сразу не появляются, каким бы простым язык ни был. Но нет — почему то считается, что на "простом" языке можно писать любому неучу.

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

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

Кроме того, с .Net cкорост обученяи много выше С++ потому что есть такие инструменты как Reflector или, например, качественные средства рефакторинга.

ГВ>mpl и concept_check, как раз далеко не всегда нужны (не считая внутренностей буста). Но я в упор не понимаю, почему нужно так резко шугаться буста в части остальных библиотек.

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

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

ГВ>Вот это как раз для меня один из самых больших парадоксов IT-отрасли. Казалось бы, навыки именно программирования нужны примерно одни и те же, что для Java, что для .Net, что для C++. Они сразу не появляются, каким бы простым язык ни был. Но нет — почему то считается, что на "простом" языке можно писать любому неучу.

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

Дело в том, что управляемые языки не содержат такого жииирного источника багов(особенно, особенно для начинающих), как проблемы с памятью. Потому, действительно, клепать формы может даже не особо обремененный знаниями "специалист". И программа не будет постоянно падать, или отжирать память, как если бы было на плюсах у программиста такого же уровня. Станет ли такой человек профи, или нет — вопрос второй. Но порог вхождения для написания несложного коммерческого говнософта(этот факт никого, кстати, не волнует: главное, чтобы деньги приносил) у С/C++ и у управляемых языков весьма различен.

То есть, дело в задачах. При написании сложных систем, требоватальных к памяти/производительности/устойчивости граница не так заметна. На чем не пиши, нужны профессионалы(и тут уже нужны знания и про нюансы работы GC, и понимание, почему ресурсы надо обязательно освобождать, и прочая тысяча нюансов). А если нужно написать софтину о десятке формочек... За памятью сборщик проследит, а других таких масштабных источников багов для такого приложения вроде как уже и нет.

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

ГВ>>Вот это как раз для меня один из самых больших парадоксов IT-отрасли. Казалось бы, навыки именно программирования нужны примерно одни и те же, что для Java, что для .Net, что для C++.

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

Упс. Не, ну это полный ништяк. Программист, который не понимает, что такое сопоставление символического имени блоку бинарного кода — это анекдот (я в курсе, что их много есть, менее анекдотичными они от этого не становятся). Собственно, этих, альтернативно одарённых, я в расчёт не беру. А в противном случае, линковку как-то особенно "понимать" никакой нужды нет.

I>Кроме того, в самом С++ столько подводных камней, что даже для опытного разработчика довольно сложно пересесть на плюсы.

Никто не говорит "сразу", но и не три года, ёлки зелёные!

ГВ>>Они сразу не появляются, каким бы простым язык ни был. Но нет — почему то считается, что на "простом" языке можно писать любому неучу.

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

I>На простом языке можно сосредоточиться на задаче, а не заниматься всем подряд.
I>Кроме того, с .Net cкорост обученяи много выше С++ потому что есть такие инструменты как Reflector или, например, качественные средства рефакторинга.

Чего? Ну ладно, рефлектор — он, по крайней мере, может дать доступ к образцам кода. Но средства рефакторинга...

ГВ>>mpl и concept_check, как раз далеко не всегда нужны (не считая внутренностей буста). Но я в упор не понимаю, почему нужно так резко шугаться буста в части остальных библиотек.

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

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

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

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

Именно.

E__>Но порог вхождения для написания несложного коммерческого говнософта(этот факт никого, кстати, не волнует: главное, чтобы деньги приносил) у С/C++ и у управляемых языков весьма различен.

Вот! Понимаешь, я сказал то же самое, но в более обтекаемой форме. Именно, что для, э-э-э... Для софта, склёпанного на коленке

как раз критична "скорость вхождения". Вчера таксист, сегодня — комбобоксорасполагатель. "Расставляю комбобоксы за еду! А за бутерброд дополнительно накидаю кнопочек!"

E__>То есть, дело в задачах. При написании сложных систем, требоватальных к памяти/производительности/устойчивости граница не так заметна. На чем не пиши, нужны профессионалы(и тут уже нужны знания и про нюансы работы GC, и понимание, почему ресурсы надо обязательно освобождать, и прочая тысяча нюансов). А если нужно написать софтину о десятке формочек... За памятью сборщик проследит, а других таких масштабных источников багов для такого приложения вроде как уже и нет.

Угу, угу. Только, ИМХО, дело не столько в задачах, сколько в отношении к потребителю этих самых задач, то есть — решений.

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

I>>>Ну да, есть проектов, меньше статпогрешности
MC>>Извини, я не смог уловить смысла этого высказывания.
I>Это значит что Лиспа в индустрии по большому счету не существует, т.к. проектов на нем, хучь по чем меряй, меньше статпогрешности.

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

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

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

Почему только "управляемые" языки? (нет, эта ненавязчивая реклама везде достанет...)
Куда делись еще сотня названий.
Да и в управляемых средах легко похожие проблемы заиметь, достаточно подергать winapi или неуправляемые dll.
И когда это у "специалистов" были проблемы со средствами воспроизводства г..кода.
Еще со времен виндоус 3.1 было на чем оттянуться.
Среднее время клепания формочки/отчета, я заметил, некая константа, которая последние лет 10 стабильна.

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

I>>>>Ну да, есть проектов, меньше статпогрешности
MC>>>Извини, я не смог уловить смысла этого высказывания.
I>>Это значит что Лиспа в индустрии по большому счету не существует, т.к. проектов на нем, хучь по чем меряй, меньше статпогрешности.

ГВ>Я бы сказал так: тем, кто использует лисп, глубоко плевать на способы измерения индустрии.

Что с того ?

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

ГВ>Упс. Не, ну это полный ништяк. Программист, который не понимает, что такое сопоставление символического имени блоку бинарного кода — это анекдот (я в курсе, что их много есть, менее анекдотичными они от этого не становятся). Собственно, этих, альтернативно одарённых, я в расчёт не беру. А в противном случае, линковку как-то особенно "понимать" никакой нужды нет.

При чем здесь понимание линковки ? Речь о практическх навыках работы с линкером. И линкер это не единственная проблема.

I>>Кроме того, с .Net cкорост обученяи много выше С++ потому что есть такие инструменты как Reflector или, например, качественные средства рефакторинга.

ГВ>Чего? Ну ладно, рефлектор — он, по крайней мере, может дать доступ к образцам кода. Но средства рефакторинга...

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

В С++ во первых, средства рефакторинга слабее, во вторых, компиляция слишком долгая.

Кроме того, в С++ затруднено юниттестирование, написание моков.

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

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

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

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

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

ГВ>>Упс. Не, ну это полный ништяк. Программист, который не понимает, что такое сопоставление символического имени блоку бинарного кода — это анекдот (я в курсе, что их много есть, менее анекдотичными они от этого не становятся). Собственно, этих, альтернативно одарённых, я в расчёт не беру. А в противном случае, линковку как-то особенно "понимать" никакой нужды нет.
I>При чем здесь понимание линковки ?

При том, что это самое сопоставление — есть краеугольный камень линковки. ИМХО, "не понятной" она может быть, только если не понимать вышеуказанного. Где там ещё китайская грамота? В декорировании имён?

I>Речь о практическх навыках работы с линкером. И линкер это не единственная проблема.

Хм. Ты навёл меня на клёвую мысль, надо написать в резюме: "практические навыки работы с редактором связей — 17 лет".

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

I>>>Кроме того, с .Net cкорост обученяи много выше С++ потому что есть такие инструменты как Reflector или, например, качественные средства рефакторинга.
ГВ>>Чего? Ну ладно, рефлектор — он, по крайней мере, может дать доступ к образцам кода. Но средства рефакторинга...
I>Средства рефакторинга помогают преобразовать код к понятному виду. Не долбить целый день одно и то же, а за полчаса привести к нужному виду и двигаться дальше.

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

I>В С++ во первых, средства рефакторинга слабее, во вторых, компиляция слишком долгая.

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

I>Кроме того, в С++ затруднено юниттестирование, написание моков.

При чём тут обучение языку?

Чтобы вписывать нужные буквы в мок, необходимо уже понимать — что, куда, почему. А проще всего проверять себя маленькими программками, где нет ничего лишнего. Зачем тут какие-то специальные средства мокогенерирования? Мы всё ещё про обучение?

I>>>Шугаться не нужно, но практика показывает, что буст даже у сиплюсника можно не спрашивать, если опыт работы менее 3х лет.
ГВ>>Я говорю "шугаться", поскольку был свидетелем такого "шугания" — даже приходилось по требованию заказчика (внимание — хи-хи) кромсать буст, чтобы не "пугать программистов". Идиотизма ситуации это не отменяет, но зато какая основа для положительных эмоций!

I>Я сильно понимаю этого заказчика — буст увеличивает зависимость от человеческого фактора.

(Отметка на память: посмотреть список авторов буста, буду знать, от кого зависят проекты. В прочем, я отвлёкся.)

I>Если не дай бог он не сможет найти вторую такую же команду, то придется выкидывать или гору денег или похоронить проект.

Одному мне это кажется паранойей (буст — общеупотребительный инструмент)? Знаешь, если так рассуждать, то в программирование вообще лучше не соваться, а то, так и будешь всё время переписывать продукт, пугаясь того, что чайников на разработку не найдётся. Что самое забавное, как раз C++ на сегодняшний день — самый, что ни на есть, стабильный во всех отношениях язык, в отличие от. А буст вообще частью уже перекочевал в стандарт.

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

I>>>>>Ну да, есть проектов, меньше статпогрешности
MC>>>>Извини, я не смог уловить смысла этого высказывания.
I>>>Это значит что Лиспа в индустрии по большому счету не существует, т.к. проектов на нем, хучь по чем меряй, меньше статпогрешности.
ГВ>>Я бы сказал так: тем, кто использует лисп, глубоко плевать на способы измерения индустрии.

I>Что с того ?

Ничего. Это моё алаверды в порядке пикировки. К этому:

Нужен интрумент для решения текущих задач бизнеса, а Лисп — нет, не нужен.

Оценки объёма сектора лиспа (тем более — умозрительные) никак не влияют на процесс его использования теми, кто хочет лисп использовать. Вот такая загадка природы.

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

ГВ>При том, что это самое сопоставление — есть краеугольный камень линковки. ИМХО, "не понятной" она может быть, только если не понимать вышеуказанного. Где там ещё китайская грамота? В декорировании имён?

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

ГВ>Хм. Ты навёл меня на клёвую мысль, надо написать в резюме: "практические навыки работы с редактором связей — 17 лет".

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

Это не смешно, особенно когда приходтся исправлять какую нибудь lnk2005. Причин — вагоны.

ГВ>>>Чего? Ну ладно, рефлектор — он, по крайней мере, может дать доступ к образцам кода. Но средства рефакторинга...
I>>Средства рефакторинга помогают преобразовать код к понятному виду. Не долбить целый день одно и то же, а за полчаса привести к нужному виду и двигаться дальше.

ГВ>Есть мнение, что количество нужных видов растёт прямо пропорционально лёгкости их получения. Есть также ещё одно мнение: что время получения финального вида слабо зависит от количества промежуточных прикидок. Почему-то я согласен с ними обоими.

А какое

ГВ>Хм. Либо ученик юзает шаблоны, тогда будет большое время компиляции, но квалификация уже очевидна; либо ученик шарахается шаблонов, но тогда откуда взяться большому времени компиляции? Неужели он, пугающийся шаблонов, собирает настолько большой проект?

Это зависит от проекта, а не от ученика.

I>>Кроме того, в С++ затруднено юниттестирование, написание моков.

ГВ>При чём тут обучение языку?

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

ГВ>>При том, что это самое сопоставление — есть краеугольный камень линковки. ИМХО, "не понятной" она может быть, только если не понимать вышеуказанного. Где там ещё китайская грамота? В декорировании имён?

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

А ты уверен, что причина именно в сложности понимания работы линкера? Может, дело в чём-то сильно-сильно другом?

ГВ>>Хм. Ты навёл меня на клёвую мысль, надо написать в резюме: "практические навыки работы с редактором связей — 17 лет".

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

I>Это не смешно, особенно когда приходтся исправлять какую нибудь lnk2005. Причин — вагоны.

Знамо дело, не смешно. Не знать, что такое редактирование связей, да ещё нарваться на lnk2005 — можно только посочувствовать.

ГВ>>>>Чего? Ну ладно, рефлектор — он, по крайней мере, может дать доступ к образцам кода. Но средства рефакторинга...
I>>>Средства рефакторинга помогают преобразовать код к понятному виду. Не долбить целый день одно и то же, а за полчаса привести к нужному виду и двигаться дальше.
ГВ>>Есть мнение, что количество нужных видов растёт прямо пропорционально лёгкости их получения. Есть также ещё одно мнение: что время получения финального вида слабо зависит от количества промежуточных прикидок. Почему-то я согласен с ними обоими.

I>А какое
Похоже, фраза оборвана на полуслове.

ГВ>>Хм. Либо ученик юзает шаблоны, тогда будет большое время компиляции, но квалификация уже очевидна; либо ученик шарахается шаблонов, но тогда откуда взяться большому времени компиляции? Неужели он, пугающийся шаблонов, собирает настолько большой проект?
I>Это зависит от проекта, а не от ученика.

Это я понимаю, знаешь ли. Я никак не соображу, как связать "большой проект" с "учебными программами".

Наверное, я старомоден.

I>>>Кроме того, в С++ затруднено юниттестирование, написание моков.
ГВ>>При чём тут обучение языку?

Чтобы вписывать нужные буквы в мок, необходимо уже понимать — что, куда, почему. А проще всего проверять себя маленькими программками, где нет ничего лишнего. Зачем тут какие-то специальные средства мокогенерирования?
I>Это ж каменный век.
ГВ>>Мы всё ещё про обучение?
I>Да, это все оно же. Моки, тесты снижают порог вхождения в проект/фреймворк.

Хорошо, я согласен, что сейчас пытаюсь опровергнуть формально корректные высказывания. Меня смущает другое. Давай, разобьём задачи, с которыми сталкивается ученик, когда он пишет исследовательскую программу, на две составляющие: 1) написать саму такую программу, 2) понять, что происходит, "поиграться" с кодом, объяснить результаты. Написание программы снова разобьём на: 1.1) написать формальный код вызовов, 1.2) наполнить формальный код функциональностью. Мокогенератор может помочь на стадии 1.1, плюс, (возможно), на 1.2. Вопрос: как относятся (1.1 + часть 1.2) к (1+2)? AFAIK, это примерно 0.15-0.30, остальное уходит на то, чтобы понять, какой функциональностью нужно наполнить формальный код, а после — что же там на самом деле происходит. У меня бывали случаи, когда эта величина колебалась в районе 0.05 — но это уже касается сложных ситуаций, например, выяснения тонкостей работы какого-нибудь API. В пределе этот показатель стремится к нулю (написал один раз тестовую программу, потом месяц с ней периодически играешься).

Резюмирую: я не против мокогенерации самой по себе, как части обучения, но я не согласен с тем, что она значительно влияет на скорость обучения. По крайней мере, если у нас малоопытный ученик. Плюс к тому, например, для той же стандартной библиотеки в сети полно разнообразного boilerplate кода, который вполне можно использовать для исследований. А в составе буста вообще имеются уже готовые тестовые программы.

ГВ>>[...] А буст вообще частью уже перекочевал в стандарт.
I>Что с того что он в стандарте ? Его изучать чтоли не нужно ?

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

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

ГВ>>>При том, что это самое сопоставление — есть краеугольный камень линковки. ИМХО, "не понятной" она может быть, только если не понимать вышеуказанного. Где там ещё китайская грамота? В декорировании имён?

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

ГВ>А ты уверен, что причина именно в сложности понимания работы линкера? Может, дело в чём-то сильно-сильно другом?

Цитирую себя про сложность "При чем здесь понимание линковки ? Речь о практическх навыках работы с линкером."

и еще

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

I>>Это не смешно, особенно когда приходтся исправлять какую нибудь lnk2005. Причин — вагоны.

ГВ>Знамо дело, не смешно. Не знать, что такое редактирование связей, да ещё нарваться на lnk2005 — можно только посочувствовать.

Что интересно, сиплюсники с большим опытом ничем не смогли мне помочь когда был затык почти на неделю из за линкера. Все стандартные рецепты не помогли.

I>>Это зависит от проекта, а не от ученика.

ГВ>Это я понимаю, знаешь ли. Я никак не соображу, как связать "большой проект" с "учебными программами".

Наверное, я старомоден.

Ну так обучение, изучение оно не только в университете.

I>>Да, это все оно же. Моки, тесты снижают порог вхождения в проект/фреймворк.

ГВ>1) написать саму такую программу,
ГВ>2) понять, что происходит, "поиграться" с кодом, объяснить результаты.
ГВ>1.1) написать формальный код вызовов,
ГВ>1.2) наполнить формальный код функциональностью. Мокогенератор может помочь на стадии 1.1, плюс, (возможно), на 1.2.
ГВ>Вопос: как относятся (1.1 + часть 1.2) к (1+2)?

Если только написать и поиграться, то тесты не нужны вовсе

ГВ>Резюмирую: я не против мокогенерации самой по себе, как части обучения, но я не согласен с тем, что она значительно влияет на скорость обучения.

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

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

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

ГВ>>>[...] А буст вообще частью уже перекочевал в стандарт.
I>>Что с того что он в стандарте ? Его изучать чтоли не нужно ?

ГВ>Глупо от него отказываться, тем более, объясняя это трудностями поиска программистов.

Есть хороший пример про Лисп и Яху. Челы не смогли найти второго Грехема, не смогли укомплектовать комманду и в итоге вынуждены были выбросить Лисп и переписали проект на плюсах.

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

Вот представь себе,

1 ты тот семый чел из Яхи, которому надо сдават проект,
2 лисперов у тебя нет.
3 бюджет жмет
4 сроки жмут — бизнес яхи несет убытки из за отсутствия функционала

Твои действия ?

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

>>Или надо шашечки, а не ехать?

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

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

ГВ>>А ты уверен, что причина именно в сложности понимания работы линкера? Может, дело в чём-то сильно-сильно другом?
I>Цитирую себя про сложность "При чем здесь понимание линковки ? Речь о практическх навыках работы с линкером."
I>и еще
I>"Например в структуре проектов, в настройках оных проектов и тд. В итоге задача подключить либу чатенько растягивается на неделю."

Понял. Только при чём тут сам линкер-то? Запутать можно всё, что хочешь.

I>>>Это не смешно, особенно когда приходтся исправлять какую нибудь lnk2005. Причин — вагоны.
ГВ>>Знамо дело, не смешно. Не знать, что такое редактирование связей, да ещё нарваться на lnk2005 — можно только посочувствовать.

I>Что интересно, сиплюсники с большим опытом ничем не смогли мне помочь когда был затык почти на неделю из за линкера. Все стандартные рецепты не помогли.

Ну, плохо. Сочувствую. Хотя я часто язвлю в таких случаях: "Не смогли, или не захотели?"

I>>>Это зависит от проекта, а не от ученика.
ГВ>>Это я понимаю, знаешь ли. Я никак не соображу, как связать "большой проект" с "учебными программами".

Наверное, я старомоден.

I>Ну так обучение, изучение оно не только в университете.

Всё равно, никак в толк не возьму. Получается, что ты бросаешь молодняк на сопровождение большого проекта. А этот молодняк настолько юн, зелен и душевно раним, что учиться ему мешает длительное время сборки. Снова какая-то несклейка: если сотрудники не опытны, то на C++-проекты такого калибра их можно "бросить" только по велению руководства, соответственно, пугаются или нет — вопрос 115-й. А из любви к искусству (из интереса к языку) они вряд ли окажутся перед запредельно большим временем сборки, не приобретя мало-мальской квалификации.

Короче, у тебя тут куча разрозненных фактов, смешанных чёрт-те как. Пудри мозги кому-нибудь другому, а?

I>>>Да, это все оно же. Моки, тесты снижают порог вхождения в проект/фреймворк.

ГВ>>1) написать саму такую программу,
ГВ>>2) понять, что происходит, "поиграться" с кодом, объяснить результаты.
ГВ>>1.1) написать формальный код вызовов,
ГВ>>1.2) наполнить формальный код функциональностью. Мокогенератор может помочь на стадии 1.1, плюс, (возможно), на 1.2.
ГВ>>Вопос: как относятся (1.1 + часть 1.2) к (1+2)?

I>Если только написать и поиграться, то тесты не нужны вовсе

Назови хоть груздём.

ГВ>>Резюмирую: я не против мокогенерации самой по себе, как части обучения, но я не согласен с тем, что она значительно влияет на скорость обучения.
I>Если есть тесты, новичек может поиграться с кодом, который писался группой серьезных девелоперов.

Так всё же, тесты "не нужны", или "нужны"? Полезны или нет? Давай, ты сделашь дефрагментацию своих тезисов? Потом, если тесты написаны опытными девелоперами, то откуда берётся влияние мокогенератора? Тесты-то уже есть!

>>По крайней мере, если у нас малоопытный ученик. Плюс к тому, например, для той же стандартной библиотеки в сети полно разнообразного boilerplate кода, который вполне можно использовать для исследований. А в составе буста вообще имеются уже готовые тестовые программы.
I>Это же неудобно — рыться где то, искать и тд. Так все в одном солюшне, получаешь целый полигон для испытаний в одном флаконе.

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

ГВ>>>>[...] А буст вообще частью уже перекочевал в стандарт.
I>>>Что с того что он в стандарте ? Его изучать чтоли не нужно ?

ГВ>>Глупо от него отказываться, тем более, объясняя это трудностями поиска программистов.

I>Есть хороший пример про Лисп и Яху. Челы не смогли найти второго Грехема, не смогли укомплектовать комманду и в итоге вынуждены были выбросить Лисп и переписали проект на плюсах.
I>Это значит, что если есть сложность подбора спецов, то инструмент(язык) не пригоден для использования в бизнесе.

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

I>Вот представь себе,

Ха-ха, пофантазируем.

I>1 ты тот семый чел из Яхи, которому надо сдават проект,
I>2 лисперов у тебя нет.

Куда они делись?

I>3 бюджет жмет

Противоречивая ситуация: разработчиков нет, а бюджет есть. Откуда он взялся, если не ясна потребность? Руководство — идиоты?

I>4 сроки жмут — бизнес яхи несет убытки из за отсутствия функционала

Почему свалили лисперы? Они сами ушли, или их выпинали?

I>Твои действия ?

Свалить вместе с предыдущими лисперами — идиоты не мой профиль.

Хочешь более реалистичный сценарий?

1. Yahoo покупает Viaweb как дойную корову, заранее предполагая его переписывание на C++, поскольку на самом деле покупается не столько техническая компонета, сколько клиентская база, модель сервиса, рыночный сектор... Да много чего ещё.
2. Миллионы унылых менеджеров начинают засирать мозги молодняку: "они не нашли лисперов, лисп не нужен, нужны тупые обезьянки".

Если учесть, что именно лисперам (Грэхему с компанией) Viaweb вместе с лиспом принесли весьма неплохой доход — то откуда берутся рассуждения о том, что лисп не нужен, а паче чаяния — опасен для бизнеса? ИМХО, всё строго наоборот.

Потом знаешь, "не нашли лисперов" в стране, где лисп входит в программу в/о — это что-то запредельное.

ГВ>1. Yahoo покупает Viaweb как дойную корову, заранее предполагая его переписывание на C++, поскольку на самом деле покупается не столько техническая компонета, сколько клиентская база, модель сервиса, рыночный сектор... Да много чего ещё.

1.1. Yahoo переписывает Viaweb, интегрируя его в свои инфраструктуры, не заморачиваясь каким-то поиском дополнительных специалистов вообще (кроме обыкновенной текучки). Тарахтеть в сети при этом она может о чём угодно — о том, что второго Грэма найти не удалось, о погоде на Марсе, о котировках акций Sun, о великом будущем интернета — это всё не имеет никакого значения.

1.2. Грэму это вообще всё до лампочки — он продукт продал, а дальше не его дело. Больше того, такая трескотня ему даже на руку — "короля играет свита". Его персональных достоинств это никак не умаляет, а "корпорации" не ругает только ленивый — Yahoo от этого ни холодно, ни жарко.

ГВ>2. Миллионы унылых менеджеров начинают засирать мозги молодняку: "они не нашли лисперов, лисп не нужен, нужны тупые обезьянки".

...правда, почему-то, эти "миллионы" даже в Yahoo не работают. Но точно знают, что лисп мешает бизнесу, иллюстрируя примером Yahoo.

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

ГВ>Понял. Только при чём тут сам линкер-то? Запутать можно всё, что хочешь.

Наличие линкера это лишняя сложность, это так или иначе придется освоить, при чем это чисто балласт.

I>>Ну так обучение, изучение оно не только в университете.

...

я тут скипнул, ни вижу смысла объяснять

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

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

I>>Есть хороший пример про Лисп и Яху. Челы не смогли найти второго Грехема, не смогли укомплектовать комманду и в итоге вынуждены были выбросить Лисп и переписали проект на плюсах.
I>>Это значит, что если есть сложность подбора спецов, то инструмент(язык) не пригоден для использования в бизнесе.

ГВ>Это значит, что в данном случае переписали продукт с лиспа на плюсы, больше это ничего не значит.

Это уже следствие. Фишка в том, что это вынужденный шаг.

I>>1 ты тот семый чел из Яхи, которому надо сдават проект,
I>>2 лисперов у тебя нет.

ГВ>Куда они делись?

Ушли вместе с Грехемом.

I>>3 бюджет жмет

ГВ>Противоречивая ситуация: разработчиков нет, а бюджет есть. Откуда он взялся, если не ясна потребность?
>Руководство — идиоты?

А как ты хотел, сначала бюджет, а потом разработчики ? Потребность вполне ясна, цели проекта — все предельно ясно.

I>>4 сроки жмут — бизнес яхи несет убытки из за отсутствия функционала

ГВ>Почему свалили лисперы? Они сами ушли, или их выпинали?

А это неважно абсолютно. В данном случае Грехем сам продал свой бизнес.

I>>Твои действия ?

ГВ>Свалить вместе с предыдущими лисперами — идиоты не мой профиль.

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

ГВ>Хочешь более реалистичный сценарий?

ГВ>1. Yahoo покупает Viaweb как дойную корову, заранее предполагая его переписывание на C++, поскольку на самом деле покупается не столько техническая компонета, сколько клиентская база, модель сервиса, рыночный сектор... Да много чего ещё.

Разумется они предполагали это. Только С++ не от балды взяли, а посчитали риски, затраты и тд.

ГВ>2. Миллионы унылых менеджеров начинают засирать мозги молодняку: "они не нашли лисперов, лисп не нужен, нужны тупые обезьянки".

ГВ>Если учесть, что именно лисперам (Грэхему с компанией) Viaweb вместе с лиспом принесли весьма неплохой доход — то откуда берутся рассуждения о том, что лисп не нужен, а паче чаяния — опасен для бизнеса? ИМХО, всё строго наоборот.

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

Лисп тем и опасен своей чрезмерной зависимостью от топовых специалистов.

>Потом знаешь, "не нашли лисперов" в стране, где лисп входит в программу в/о — это что-то запредельное.

Даже в этой стране лисперов около нуля.

Вот, смотри, что сказал Грехем:

Why? Because they didn't think they'd be able to find Lisp hackers.

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

ГВ>>Понял. Только при чём тут сам линкер-то? Запутать можно всё, что хочешь.

I>Наличие линкера это лишняя сложность, это так или иначе придется освоить, при чем это чисто балласт.

Вот с этого и надо начинать. Что это просто "дополнительное что-то". Правда, вполне очевидно используемое, но не мышкой, а это "сложно".

I>>>Ну так обучение, изучение оно не только в университете.
I>...
I>я тут скипнул, ни вижу смысла объяснять

Хорошо, слив засчитан. Молодняк мне твой жалко, конечно, но что поделаешь...

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

Ну, я уже понял, что согласованость посылок — ничто. Главное — что C++-отстой, лисп — опасность.

I>>>Есть хороший пример про Лисп и Яху. Челы не смогли найти второго Грехема, не смогли укомплектовать комманду и в итоге вынуждены были выбросить Лисп и переписали проект на плюсах.
I>>>Это значит, что если есть сложность подбора спецов, то инструмент(язык) не пригоден для использования в бизнесе.
ГВ>>Это значит, что в данном случае переписали продукт с лиспа на плюсы, больше это ничего не значит.

I>Это уже следствие. Фишка в том, что это вынужденный шаг.

Я одного не понимаю, как можно называть "непригодным для использования в бизнесе" инструмент, благодаря которому появился столь успешный продукт? 1 == 0? Эти люди допущены к обучению молодых, с такой-то кашей в голове. O tempora, o mores!

I>>>1 ты тот семый чел из Яхи, которому надо сдават проект,
I>>>2 лисперов у тебя нет.
ГВ>>Куда они делись?
I>Ушли вместе с Грехемом.

Угу, ну ладно. Испарились. Ну, бывает.

I>>>3 бюджет жмет
ГВ>>Противоречивая ситуация: разработчиков нет, а бюджет есть. Откуда он взялся, если не ясна потребность?
>>Руководство — идиоты?
I>А как ты хотел, сначала бюджет, а потом разработчики ? Потребность вполне ясна, цели проекта — все предельно ясно.

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

I>>>4 сроки жмут — бизнес яхи несет убытки из за отсутствия функционала
ГВ>>Почему свалили лисперы? Они сами ушли, или их выпинали?
I>А это неважно абсолютно. В данном случае Грехем сам продал свой бизнес.

Как это — не важно? Очень даже важно — я не собираюсь занимать вакантное место промеж жерновов... Ладно, я понял. Ты предлагаешь проанализировать ситуацию с позиций топ-менеджмента, только что отвалившего 40 мегабаксов (кажется, столько) за продукт. Ну что же, пофантазируем.

I>>>Твои действия ?
ГВ>>Свалить вместе с предыдущими лисперами — идиоты не мой профиль.

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

Если это топ-менеджмент Yahoo, принявший решение о покупке сервиса — тогда логика вполне ясна. Компания купила проект, ключевые специалисты свалили. Что делать? Отдали проект своим специалистам, а кому ещё? Те оказались перед дилеммой: изучать лисп, либо переписать всё на привычном языке. Изучить лисп, наверное, было бы прикольно, только, подозреваю, никаких пряников за это им бы не обломилось — всего лишь, ещё один "спасённый" проект. Следовательно — переписываем! Специалисты радостно потирают руки, руководство получает сценарий к действию, неопределённость преодолена, все довольны. Я уверен почти на 100%, что цена переписывания при любых раскладах была не сопоставима с ценой покупки продукта, а цена покупки вряд ли создала критическую нагрузку на бюджет самой Yahoo. Следовательно — без лишнего шума переписали на том, на чём захотели. Были бы джависты — переписали бы на Java. Бюджет на переписывание всё равно отстегнули бы ровно тот, который нужен, а иначе вся покупка — коту под хвост. Действительно, тут есть ещё одна альтернатива — искать "lisp hackers", которые заменят Грэма, а не просто знают лисп, но это игра без определённого итога — то ли найдём, то ли нет. А тут можно начинать действовать прямо сейчас.

То есть вся эта ситуация никоим образом не бросает тень на сам лисп. Напротив: не будь лиспа, Грэм не заработал бы свои сколько-то там в шестой степени.

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

Ну а ситуация, к которой ты клонишь: "компания купила продукт на LANG, а потом разорилась из-за отсутствия специалистов" — это полный абсурд.

ГВ>>Хочешь более реалистичный сценарий?
ГВ>>1. Yahoo покупает Viaweb как дойную корову, заранее предполагая его переписывание на C++, поскольку на самом деле покупается не столько техническая компонета, сколько клиентская база, модель сервиса, рыночный сектор... Да много чего ещё.
I>Разумется они предполагали это. Только С++ не от балды взяли, а посчитали риски, затраты и тд.

Ты вторую часть моего предложения прочёл?

ГВ>>2. Миллионы унылых менеджеров начинают засирать мозги молодняку: "они не нашли лисперов, лисп не нужен, нужны тупые обезьянки".
ГВ>>Если учесть, что именно лисперам (Грэхему с компанией) Viaweb вместе с лиспом принесли весьма неплохой доход — то откуда берутся рассуждения о том, что лисп не нужен, а паче чаяния — опасен для бизнеса? ИМХО, всё строго наоборот.

I>О том, что нужно мощное средство разработки, никто не спорит. Но глупо отрицать такие риски, как отсутствие специалистов.
I>Лисп тем и опасен своей чрезмерной зависимостью от топовых специалистов.

Какие ещё, к чёртовой бабушке, риски? У тебя всё с ног на голову поставлено. У Грэма таких рисков не было, он сам себе командир. У Yahoo — тоже никаких особых рисков, переписала и не развалилась. А если бы риск ухода Грэма был на самом деле значимым, то Yahoo, подозреваю, просто не стала бы покупать Viaweb, следовательно — он остался бы у Грэма, начинай с начала.

Потом знаешь, был бы топовый специалист — а зависимость от него всегда сложится, не зависимо от языка программирования. Почитай недавние истории от того же мыщъха — он тоже один из топовых специалистов в своей области. Что теперь? C — тоже плохой?

>>Потом знаешь, "не нашли лисперов" в стране, где лисп входит в программу в/о — это что-то запредельное.
I>Даже в этой стране лисперов около нуля.
I>Вот, смотри, что сказал Грехем:

I>

I>Why? Because they didn't think they'd be able to find Lisp hackers.

Внимательно всматриваемся в выделенное. Чем отличается hacker от "просто программиста"?

ГВ>Какие ещё, к чёртовой бабушке, риски? У тебя всё с ног на голову поставлено. У Грэма таких рисков не было, он сам себе командир. У Yahoo — тоже никаких особых рисков, переписала и не развалилась. А если бы риск ухода Грэма был на самом деле значимым, то Yahoo, подозреваю, просто не стала бы покупать Viaweb, следовательно — он остался бы у Грэма, начинай с начала.

Вот какая закавыка. Допустим, что у Yahoo нет денег на замену Грэма. Я не думаю, что в менеджменте Yahoo сидят кретины, не способные просчитать эту маленькую деталь: Грэму всё надоело — он свалил. Значит, Yahoo заранее предполагает вероятность сбегания команды. Следовательно — заранее резервирует бюджет на возможное переписывание. Во всяком случае — предполагает такую возможность, притом, что не удивительно — ничуть её не боится (за исключением менеджеров среднего звена, которым положено бояться всего). Иными словами, цена покупки Viaweb для Yahoo состоит из X+Y, где X — собственно цена продукта, а Y — цена возможного его переписывания. X определяется из переговоров с Грэмом (с определённой степенью условновсти можно сказать, что именно с Грэмом). Y — оценочно прикидывается специалистами Yahoo. Если Грэм не свалит — всем будет только лучше, но никто его не обязывает к альтруизму.

Можно ещё немного пофантазировать. Конечно, Yahoo могла написать прямую альтернативу Viaweb своими средствами. Но здесь затыка: Грэм уже всем рассвистел, какой он поворотливый, плюс к тому — он и есть вполне поворотливый. Следовательно, обыгрывать его в прямой конкурентной свалке — это нудная, сложная задача. Зачем? Проще приобрести продукт вместе с сегментом рынка. Если Грэм сотоварищи останется в Yahoo — отлично, глядишь, он ещё чего прикольного начудит, а не останется — см. выше.

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

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

I>>>>Ну так обучение, изучение оно не только в университете.
I>>...
I>>я тут скипнул, ни вижу смысла объяснять

ГВ>Хорошо, слив засчитан.

Ай, умно выпендрился, и, главное, оригинально

ГВ>Молодняк мне твой жалко, конечно, но что поделаешь...

У меня нету молодняка. Я девелопер вообще говоря. Смотрю бывает, на код молодняка, собеседования провожу и тд.

ГВ>Ну, я уже понял, что согласованость посылок — ничто. Главное — что C++-отстой, лисп — опасность.

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

ГВ>Я одного не понимаю, как можно называть "непригодным для использования в бизнесе" инструмент, благодаря которому появился столь успешный продукт? 1 == 0? Эти люди допущены к обучению молодых, с такой-то кашей в голове. O tempora, o mores!

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

I>>Ушли вместе с Грехемом.

ГВ>Угу, ну ладно. Испарились. Ну, бывает.

Грехем продал проект, а не программистов. Вроде все ясно

>>>Руководство — идиоты?
I>>А как ты хотел, сначала бюджет, а потом разработчики ? Потребность вполне ясна, цели проекта — все предельно ясно.

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

I>>А это неважно абсолютно. В данном случае Грехем сам продал свой бизнес.

ГВ>Как это — не важно? Очень даже важно — я не собираюсь занимать вакантное место промеж жерновов... Ладно, я понял. Ты предлагаешь проанализировать ситуацию с позиций топ-менеджмента, только что отвалившего 40 мегабаксов (кажется, столько) за продукт. Ну что же, пофантазируем.

Примерно столько.

ГВ>Если это топ-менеджмент Yahoo, принявший решение о покупке сервиса — тогда логика вполне ясна. Компания купила проект, ключевые специалисты свалили. Что делать? Отдали проект своим специалистам, а кому ещё? Те оказались перед дилеммой: изучать лисп, либо переписать всё на привычном языке.

Очень странная дилема, если учесть что ИТ-специалисты в той стране чуть не поголовно учили лисп в университете.

>Действительно, тут есть ещё одна альтернатива — искать "lisp hackers", которые заменят Грэма, а не просто знают лисп, но это игра без определённого итога — то ли найдём, то ли нет.

Именно это и вносит огромные риски.

>А тут можно начинать действовать прямо сейчас.

О чем я тебе и говорю.

ГВ>То есть вся эта ситуация никоим образом не бросает тень на сам лисп. Напротив: не будь лиспа, Грэм не заработал бы свои сколько-то там в шестой степени.

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

На лисп как абстракцию, конечно тень не бросает.

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

ГВ>Ну а ситуация, к которой ты клонишь: "компания купила продукт на LANG, а потом разорилась из-за отсутствия специалистов" — это полный абсурд.

Господи, сравни "компания купила продукт на LANG, и отказалась от LANG". Не нучно вычитывать то, чего нет.

I>>Разумется они предполагали это. Только С++ не от балды взяли, а посчитали риски, затраты и тд.

ГВ>Ты вторую часть моего предложения прочёл?

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

ГВ>Какие ещё, к чёртовой бабушке, риски? У тебя всё с ног на голову поставлено. У Грэма таких рисков не было, он сам себе командир.

Да, у Грема не было. Это мега показатель

А у меня, представь, зависимости от меня самого тоже нет

>У Yahoo — тоже никаких особых рисков, переписала и не развалилась.

а чуть выше ты выдал бред "компания купила продукт на LANG, а потом разорилась из-за отсутствия специалистов"

Определись что ли ?

> А если бы риск ухода Грэма был на самом деле значимым, то Yahoo, подозреваю, просто не стала бы покупать Viaweb, следовательно — он остался бы у Грэма, начинай с начала.

ГВ>Потом знаешь, был бы топовый специалист — а зависимость от него всегда сложится, не зависимо от языка программирования. Почитай недавние истории от того же мыщъха — он тоже один из топовых специалистов в своей области. Что теперь? C — тоже плохой?

Сишников в самом худшем случае где то на порядок больше чем лисперов .

Это значит, что риски из за кадров несравнимы.

I>>Даже в этой стране лисперов около нуля.
I>>Вот, смотри, что сказал Грехем:

I>>

I>>Why? Because they didn't think they'd be able to find Lisp hackers.

ГВ>Внимательно всматриваемся в выделенное.

Т.е. просто специалистов для Лиспа было недостаточно ?

Нахрена тогда этот Лисп нужен вообще ?

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

I>>>>>Ну так обучение, изучение оно не только в университете.
I>>>...
I>>>я тут скипнул, ни вижу смысла объяснять
ГВ>>Хорошо, слив засчитан.
I>Ай, умно выпендрился, и, главное, оригинально

Заметь, я был вторым.

ГВ>>Молодняк мне твой жалко, конечно, но что поделаешь...
I>У меня нету молодняка. Я девелопер вообще говоря. Смотрю бывает, на код молодняка, собеседования провожу и тд.

Уже легче.

ГВ>>Ну, я уже понял, что согласованость посылок — ничто. Главное — что C++-отстой, лисп — опасность.
I>Moq это пример того, как тесты помогают вникнуть в код. Никакие тестовые прожки этого не заменят.

Ясно.

ГВ>>Я одного не понимаю, как можно называть "непригодным для использования в бизнесе" инструмент, благодаря которому появился столь успешный продукт? 1 == 0? Эти люди допущены к обучению молодых, с такой-то кашей в голове. O tempora, o mores!
I>Предствь себе, это решаю люди которые изучали лисп в университете. Именно они отказываются от лиспа в пользу с++.

Каких людей ты имеешь в виду? Себя? Руководство Yahoo? Специалистов Yahoo?

I>>>Ушли вместе с Грехемом.
ГВ>>Угу, ну ладно. Испарились. Ну, бывает.
I>Грехем продал проект, а не программистов. Вроде все ясно

Допустим. Что это меняет? Из моих рассуждений выпадает ровно одно звено — про пребывание Грэма в Yahoo.

ГВ>>Если это топ-менеджмент Yahoo, принявший решение о покупке сервиса — тогда логика вполне ясна. Компания купила проект, ключевые специалисты свалили. Что делать? Отдали проект своим специалистам, а кому ещё? Те оказались перед дилеммой: изучать лисп, либо переписать всё на привычном языке.
I>Очень странная дилема, если учесть что ИТ-специалисты в той стране чуть не поголовно учили лисп в университете.

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

>>Действительно, тут есть ещё одна альтернатива — искать "lisp hackers", которые заменят Грэма, а не просто знают лисп, но это игра без определённого итога — то ли найдём, то ли нет.
I>Именно это и вносит огромные риски.

Обрати внимание — речь идёт о талантах, а не о "рядовых лисповиках". Пнимаешь, проблема в том, что рядовые — они везде рядовые, что на лиспе, что на бейсике. Это, если грубо, способ мышления.

>>А тут можно начинать действовать прямо сейчас.
I>О чем я тебе и говорю.

Правильно! Только ты упускаешь главное: "действовать" — означает именно, что "двигаться с места на место". Прыгать, короче говоря. Шевелиться. Пыль поднимать.

ГВ>>То есть вся эта ситуация никоим образом не бросает тень на сам лисп. Напротив: не будь лиспа, Грэм не заработал бы свои сколько-то там в шестой степени.

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

I>На лисп как абстракцию, конечно тень не бросает.
I>А на лисп как язык, сообщество и тд этот пример полностью дискредитирует.

В чьих глазах? В моих, точно, не дискредитирует.

ГВ>>Ну а ситуация, к которой ты клонишь: "компания купила продукт на LANG, а потом разорилась из-за отсутствия специалистов" — это полный абсурд.
I>Господи, сравни "компания купила продукт на LANG, и отказалась от LANG". Не нучно вычитывать то, чего нет.

Дык. А отказалась-то она почему? Не из-за того ли, что иначе вставала перед угрозой разорения? Пойми, проблема твоих рассуждений в том, что они апеллируют к фантастической ситуации: здесь никто на самом деле не мог встать перед такой угрозой из-за лиспа. Ни Грэм, ни Yahoo. Соображения я изложил в соседнем постинге. Если вкратце, то Грэму по поределению не испытывает проблем "из-за лиспа", а Yahoo по-любому готова переписать продукт, а иначе она его попросту не купила бы.

I>>>Разумется они предполагали это. Только С++ не от балды взяли, а посчитали риски, затраты и тд.
ГВ>>Ты вторую часть моего предложения прочёл?
I>Конечно. Там буквально написано, что ЗП можно выделить чуть не любые и привлечь нужных спецов.
I>И несмотря на это люди, как ты сказал, изучавшие Лисп в университете, отказываются от него в пользу С++ и Перл.

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

ГВ>>Какие ещё, к чёртовой бабушке, риски? У тебя всё с ног на голову поставлено. У Грэма таких рисков не было, он сам себе командир.
I>Да, у Грема не было. Это мега показатель

А у меня, представь, зависимости от меня самого тоже нет

Это единственный показатель, на самом деле. При условии, что "майнстрим" не промыл дыру в башке своим мутным потоком.

>>У Yahoo — тоже никаких особых рисков, переписала и не развалилась.
I>а чуть выше ты выдал бред "компания купила продукт на LANG, а потом разорилась из-за отсутствия специалистов"

Прости, к этому бреду всё время клонишь ты, постоянно апеллируя к какой-то "опасности лиспа". У компании есть ровно одна критичная опасность — разориться. Остальное — преодолимо, если оно не ведёт к гарантированному разорению. Я подозреваю, что Yahoo, покупая Viaweb, вообще могла не брать исходники. Кому они нужны при наличии своего штата специалистов?! Нужен рыночный сегмент, плюс — спецификация продукта, а сам Viaweb мог быть написан хоть на Brainfuck.

I>Определись что ли ?

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

>> А если бы риск ухода Грэма был на самом деле значимым, то Yahoo, подозреваю, просто не стала бы покупать Viaweb, следовательно — он остался бы у Грэма, начинай с начала.
ГВ>>Потом знаешь, был бы топовый специалист — а зависимость от него всегда сложится, не зависимо от языка программирования. Почитай недавние истории от того же мыщъха — он тоже один из топовых специалистов в своей области. Что теперь? C — тоже плохой?

I>Сишников в самом худшем случае где то на порядок больше чем лисперов .

Зато сишников, с таким складом мышления, как у мыщъха — днём с огнём.

I>Это значит, что риски из за кадров несравнимы.

Ничего это не значит, пока сюда не доставлены количественные интерпретации рисков в виде затрат.

I>>>Даже в этой стране лисперов около нуля.
I>>>Вот, смотри, что сказал Грехем:

I>>>

I>>>Why? Because they didn't think they'd be able to find Lisp hackers.

ГВ>>Внимательно всматриваемся в выделенное.
I>Т.е. просто специалистов для Лиспа было недостаточно ?

Нахрена тогда этот Лисп нужен вообще ?

Это означает, что "просто специалисты" не смогли бы поддерживать продукт, написанный лучшими специалистами. Ситуация классическая. Но намного вероятнее, что это означает только лишь то, что Yahoo на самом деле не слишком мучилась "выбором технологии". Повторюсь: оказалось бы под рукой много джавистов — переписали бы на Java.

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

I>>>>я тут скипнул, ни вижу смысла объяснять
ГВ>>>Хорошо, слив засчитан.
I>>Ай, умно выпендрился, и, главное, оригинально

ГВ>Заметь, я был вторым.

Ну да, это ведь я про слив написал твоей рукой, ага

I>>Предствь себе, это решаю люди которые изучали лисп в университете. Именно они отказываются от лиспа в пользу с++.

ГВ>Каких людей ты имеешь в виду? Себя? Руководство Yahoo? Специалистов Yahoo?

Да вобщем то Лисп изучают не только в Мит, а в подавляющем большинстве серьезных технических вузов.

I>>Грехем продал проект, а не программистов. Вроде все ясно

ГВ>Допустим. Что это меняет? Из моих рассуждений выпадает ровно одно звено — про пребывание Грэма в Yahoo.

Да ладн

I>>Очень странная дилема, если учесть что ИТ-специалисты в той стране чуть не поголовно учили лисп в университете.

ГВ>Почему странная? Привычный язык на то и привычный. Потом, ты же знаешь корпоративную этику: а себя работой обеспечить? Так что, дилемма, подозреваю, не настолько сильная.

>>>Действительно, тут есть ещё одна альтернатива — искать "lisp hackers", которые заменят Грэма, а не просто знают лисп, но это игра без определённого итога — то ли найдём, то ли нет.
I>>Именно это и вносит огромные риски.

ГВ>Обрати внимание — речь идёт о талантах, а не о "рядовых лисповиках". Пнимаешь, проблема в том, что рядовые — они везде рядовые, что на лиспе, что на бейсике. Это, если грубо, способ мышления.

Рядовых лисперов тоже мало. Потому в любом случае,уже просто потому, что Лисп это будет " игра без определённого итога — то ли найдём, то ли нет."

Т.е. по твоим же словам риск, неопределенность.

По этой причине лисп все свои 50 лет все время был Неуловимым Джо.

>>>А тут можно начинать действовать прямо сейчас.
I>>О чем я тебе и говорю.

ГВ>Правильно! Только ты упускаешь главное: "действовать" — означает именно, что "двигаться с места на место". Прыгать, короче говоря. Шевелиться. Пыль поднимать.

Ну да, раз сиплюсники стало быть дураки ибо только пылить умеют

Вообще говоря, чем больше выборка, тем больше шансов найти замену Грехему.

I>>На лисп как абстракцию, конечно тень не бросает.
I>>А на лисп как язык, сообщество и тд этот пример полностью дискредитирует.

ГВ>В чьих глазах? В моих, точно, не дискредитирует.

В твоих возможно и нет. А чем объяснить его распространенность ?

ГВ>Дык. А отказалась-то она почему? Не из-за того ли, что иначе вставала перед угрозой разорения?

Не было угрозы разорения. Был шанс упустить рынок и доход с этого рынка.

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

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

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

В бизнесе принято работать с тем, что есть, а не с тем, чем удобно.

Лисп из этой формулы выпадает.

ГВ>А я это запросто списываю на: а) феномен привычного языка; б) спокойствие, присущее работе в "большой компании"; в) желание поднять собственную значимость; г) сложившуюся культуру производства ПО (схоже с пунктом "а)" ).

Ага, и 50 лет Лиспу мешала эта формула.

Почему же эта формула не мешала другим языкам ?

I>>Да, у Грема не было. Это мега показатель

А у меня, представь, зависимости от меня самого тоже нет

ГВ>Это единственный показатель, на самом деле.

Это тавтология а не показатель.

>При условии, что "майнстрим" не промыл дыру в башке своим мутным потоком.

Майнстрим подчиняется бизнесу,а бизнес требует определенность.

Люди готовы заплатить деньги, но хотят иметь определенность.

Только зависимостью от топ-специалистов Лисп устраняет начисто эту определенность.

>У компании есть ровно одна критичная опасность — разориться. Остальное — преодолимо, если оно не ведёт к гарантированному разорению.

Нужна определенность, которой нет у Лиспа.

>Я подозреваю, что Yahoo, покупая Viaweb, вообще могла не брать исходники. Кому они нужны при наличии своего штата специалистов?! Нужен рыночный сегмент, плюс — спецификация продукта, а сам Viaweb мог быть написан хоть на Brainfuck.

Это значит, что ценность Лиспа в бизнесе равняется ценности Брейнфака этого.

I>>Определись что ли ?

ГВ>Встречная просьба того же свойства: доведи свои посылки до конца, реши силлогизм(ы), наконец, которых ты сам понасоздавал.

Посылки вполне простые.

ГВ>Зато сишников, с таким складом мышления, как у мыщъха — днём с огнём.

Много больше, чем лисперов.

ГВ>Ничего это не значит, пока сюда не доставлены количественные интерпретации рисков в виде затрат.

Ну ты и дал. Кто ж тебе неопределенность числом определит ? Это ж секрет философского камня

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

Естественно. Бизнес работает с тем что есть, а не с тем, что удобно.

Лисп в бизнес за 50 лет и не попал.

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

I>>>>>я тут скипнул, ни вижу смысла объяснять
ГВ>>>>Хорошо, слив засчитан.
I>>>Ай, умно выпендрился, и, главное, оригинально

ГВ>>Заметь, я был вторым.
I>Ну да, это ведь я про слив написал твоей рукой, ага

Не, сначала ты сказал, что не видишь смысла объяснять (я, правда, подозреваю, что дело в том, что ты где-то наскочил на неразрешимое противоречие в своих доводах, но это ведь пустые домыслы, правда?), а потом я "засчитал слив". Считай это эквивалентом: "ну нет, так — нет".

I>>>Предствь себе, это решаю люди которые изучали лисп в университете. Именно они отказываются от лиспа в пользу с++.
ГВ>>Каких людей ты имеешь в виду? Себя? Руководство Yahoo? Специалистов Yahoo?
I>Да вобщем то Лисп изучают не только в Мит, а в подавляющем большинстве серьезных технических вузов.

Так всё же — кто имеется в виду?

I>>>Грехем продал проект, а не программистов. Вроде все ясно

ГВ>>Допустим. Что это меняет? Из моих рассуждений выпадает ровно одно звено — про пребывание Грэма в Yahoo.
I>Да ладн

Угу.

I>>>Очень странная дилема, если учесть что ИТ-специалисты в той стране чуть не поголовно учили лисп в университете.
ГВ>>Почему странная? Привычный язык на то и привычный. Потом, ты же знаешь корпоративную этику: а себя работой обеспечить? Так что, дилемма, подозреваю, не настолько сильная.
>>>>Действительно, тут есть ещё одна альтернатива — искать "lisp hackers", которые заменят Грэма, а не просто знают лисп, но это игра без определённого итога — то ли найдём, то ли нет.
I>>>Именно это и вносит огромные риски.
ГВ>>Обрати внимание — речь идёт о талантах, а не о "рядовых лисповиках". Пнимаешь, проблема в том, что рядовые — они везде рядовые, что на лиспе, что на бейсике. Это, если грубо, способ мышления.
I>Рядовых лисперов тоже мало. Потому в любом случае,уже просто потому, что Лисп это будет " игра без определённого итога — то ли найдём, то ли нет."

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

I>Т.е. по твоим же словам риск, неопределенность.
I>По этой причине лисп все свои 50 лет все время был Неуловимым Джо.

Ерунда. Если бы это было на самом деле так, откуда бы взялись стандарты? Он же никому не нужен? Ты покури историю лиспа — он очень даже нужен. Даже лисп-процессоры с аппаратно реализованным лиспом выпускали.

У меня есть другая гипотеза, как мне кажется, более правдоподобная. Единственная проблема лиспа, действительно значимая для покупателей — существенно меньшее быстродействие, чем у того же C (по крайней мере, так было в старые добрые времена). Этот вот аргумент весит намного больше, чем все разговоры относительно недоступности специалистов. Почему? Потому что быстродействие — это критерий, по которому продукт оценивают покупатели, без которых никакого бизнеса, как ты понимаешь, не бывает. Особенно яростно эту оценку использовали в пору больших машин и маленьких (по нашим меркам) программ. Соответственно, продать медленную программу, да ещё и на интерпретируемом языке было гораздо сложнее, чем быструю, где, к тому же, алгоритмы превращены в бинарный код. ИМХО, именно это и послужило толчком к тому, что очень много места заняли алголоподобные языки. А сейчас — да, зачастую действуют "по традиции".

>>>>А тут можно начинать действовать прямо сейчас.
I>>>О чем я тебе и говорю.

ГВ>>Правильно! Только ты упускаешь главное: "действовать" — означает именно, что "двигаться с места на место". Прыгать, короче говоря. Шевелиться. Пыль поднимать.

I>Ну да, раз сиплюсники стало быть дураки ибо только пылить умеют

Вообще говоря, чем больше выборка, тем больше шансов найти замену Грехему.

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

I>>>На лисп как абстракцию, конечно тень не бросает.
I>>>А на лисп как язык, сообщество и тд этот пример полностью дискредитирует.
ГВ>>В чьих глазах? В моих, точно, не дискредитирует.
I>В твоих возможно и нет. А чем объяснить его распространенность ?

Мы ещё не выяснили, в чьих глазах дискредитирован лисп.

ГВ>>Дык. А отказалась-то она почему? Не из-за того ли, что иначе вставала перед угрозой разорения?
I>Не было угрозы разорения. Был шанс упустить рынок и доход с этого рынка.

Хорошо, пусть так. Да, была угроза упустить рынок из-за остановки развития Viaweb. Однако, не смотря на такую угрозу, Yahoo всё же приобрела Viaweb, считай, заплатив за него цену покупки + цену переписывания. Следовательно, лисп отлично показал себя, принеся прибыль:

— Грэму (здесь всё очевидно);
— Потребителям Viaweb (иначе бы их не было);
— Yahoo (прототип экономит уйму времени и сил).

Так какие угрозы создаёт лисп, не подскажешь?

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

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

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

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

Ну, если абстрагироваться от скулосводящей формулировки — то да, так и есть. Не хрен стоять на месте — нужно бежать.

I>Лисп из этой формулы выпадает.

Я тут формулы не увидел. Заклинание — да, а формулу — нет.

ГВ>>А я это запросто списываю на: а) феномен привычного языка; б) спокойствие, присущее работе в "большой компании"; в) желание поднять собственную значимость; г) сложившуюся культуру производства ПО (схоже с пунктом "а)" ).

I>Ага, и 50 лет Лиспу мешала эта формула.
I>Почему же эта формула не мешала другим языкам ?

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

I>>>Да, у Грема не было. Это мега показатель

А у меня, представь, зависимости от меня самого тоже нет

ГВ>>Это единственный показатель, на самом деле.
I>Это тавтология а не показатель.

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

>>При условии, что "майнстрим" не промыл дыру в башке своим мутным потоком.
I>Майнстрим подчиняется бизнесу,а бизнес требует определенность.

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

I>Люди готовы заплатить деньги, но хотят иметь определенность.
I>Только зависимостью от топ-специалистов Лисп устраняет начисто эту определенность.

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

>>У компании есть ровно одна критичная опасность — разориться. Остальное — преодолимо, если оно не ведёт к гарантированному разорению.
I>Нужна определенность, которой нет у Лиспа.

Почему-то Грэм обошёлся без этой самой определённости.

>>Я подозреваю, что Yahoo, покупая Viaweb, вообще могла не брать исходники. Кому они нужны при наличии своего штата специалистов?! Нужен рыночный сегмент, плюс — спецификация продукта, а сам Viaweb мог быть написан хоть на Brainfuck.

I>Это значит, что ценность Лиспа в бизнесе равняется ценности Брейнфака этого.

Ну я уже понял, что то, чем занимался Грэм — это не бизнес, а вообще не пойми, что.

I>>>Определись что ли ?

ГВ>>Встречная просьба того же свойства: доведи свои посылки до конца, реши силлогизм(ы), наконец, которых ты сам понасоздавал.
I>Посылки вполне простые.

Реши, реши. Только прими во внимание, что Viaweb — это продукт, а Грэм тоже занимался бизнесом, при этом посмеиваясь над майнстримом. Вот прими во внимание эти условия, а потом докажи, что бизнес нуждается в майнстриме, ему не нужен лисп и т.п.

ГВ>>Зато сишников, с таким складом мышления, как у мыщъха — днём с огнём.
I>Много больше, чем лисперов.

Считал?

ГВ>>Ничего это не значит, пока сюда не доставлены количественные интерпретации рисков в виде затрат.
I>Ну ты и дал. Кто ж тебе неопределенность числом определит ? Это ж секрет философского камня

Как тогда рисками управлять? "Здесь страшно, сюда не ходи!", так, что ли?

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

I>Естественно. Бизнес работает с тем что есть, а не с тем, что удобно.

Бизнес бывает разный.

I>Лисп в бизнес за 50 лет и не попал.

Это уже апофеоз.

Грэм, надо думать, не бизнесмен.

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

I>Только зависимостью от топ-специалистов Лисп устраняет начисто эту определенность.

Тут не важен лисп, зависимость от С++ или C# топ специалистов делает тоже самое. Но именно такие
специалисты и создают (или участвуют) стартапы и продукты которые потом покупают те же монстры.
Риск неопределенности компенсируется возможной большой прибылью.

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

I>Это значит, что ценность Лиспа в бизнесе равняется ценности Брейнфака этого.

Ценность лиспа равна возможности привлекать высококвалифицированных хорошо мотивированных специалистов.

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

I>>Это значит, что ценность Лиспа в бизнесе равняется ценности Брейнфака этого.

FR>Ценность лиспа равна возможности привлекать высококвалифицированных хорошо мотивированных специалистов.

Ну то есть нулю

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

FR>>Ценность лиспа равна возможности привлекать высококвалифицированных хорошо мотивированных специалистов.

I>Ну то есть нулю

Если такие специалисты не нужны то да

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

ГВ>Не, сначала ты сказал, что не видишь смысла объяснять (я, правда, подозреваю, что дело в том, что ты где-то наскочил на неразрешимое противоречие в своих доводах, но это ведь пустые домыслы, правда?),

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

ГВ>>>Каких людей ты имеешь в виду? Себя? Руководство Yahoo? Специалистов Yahoo?
I>>Да вобщем то Лисп изучают не только в Мит, а в подавляющем большинстве серьезных технических вузов.

ГВ>Так всё же — кто имеется в виду?

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

Я более чем уверен, Яху прорабатывала этот вопрос очень тщательно.

I>>Рядовых лисперов тоже мало. Потому в любом случае,уже просто потому, что Лисп это будет " игра без определённого итога — то ли найдём, то ли нет."

ГВ>Тебе не кажется, что ты сам себе противоречишь? С одной стороны, ты соглашаешься со мной, что лисп изучал почти каждый IT-шник, а с другой — что рядовых лисперов мало. Ты уж определись, ладно?

Лиспер, дотнетчих, сиплюсник, джавист — всегда и везде название дается по основному направлению.

Потому если ты чего то изучал, а пишешь на С++ — значит ты сиплюсник.

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

I>>По этой причине лисп все свои 50 лет все время был Неуловимым Джо.

ГВ>Ерунда. Если бы это было на самом деле так, откуда бы взялись стандарты? Он же никому не нужен? Ты покури историю лиспа — он очень даже нужен. Даже лисп-процессоры с аппаратно реализованным лиспом выпускали.

Болтается на грани статпогрешности. Его всегда обходили слабенькие, уродливые языки

Лисп-процессоры никому не нужны. Потому и не прижилось это дело.

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

Перформанс никогда не был определяющим фактором. Комфорт программиста, инструментарий — это много важнее.

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

Этот аргумент ровно ничего не весит.

>Особенно яростно эту оценку использовали в пору больших машин и маленьких (по нашим меркам) программ.

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

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

И поэтому люди писали на тормозных и убогих, а не на тормозных и мощных ?

ГВ>Не надо передёргивать. Я имел в виду, что в первом случае (поиски Грэма-2) пришлось бы долго сидеть без дела, а в случае переписывания муравейник зашевелился немедленно. Сиплюсплюсники там, перлисты — никакой разницы. Важен сам процесс шевеления, он вообще может по кругу ходить.

Ну то есть все равно дураки, пылить только могут и ходить кругами ? К этой формуле прилепить бы дороги — получится классическая дилема

I>>В твоих возможно и нет. А чем объяснить его распространенность ?

ГВ>Мы ещё не выяснили, в чьих глазах дискредитирован лисп.

В глазах тех, кто изучал его и кто после этого не используеи этот язык.

ГВ>Хорошо, пусть так. Да, была угроза упустить рынок из-за остановки развития Viaweb. Однако, не смотря на такую угрозу, Yahoo всё же приобрела Viaweb, считай, заплатив за него цену покупки + цену переписывания. Следовательно, лисп отлично показал себя, принеся прибыль:

ГВ>- Грэму (здесь всё очевидно);
ГВ>- Потребителям Viaweb (иначе бы их не было);
ГВ>- Yahoo (прототип экономит уйму времени и сил).

ГВ>Так какие угрозы создаёт лисп, не подскажешь?

Дважды два это три или пять, не подскажешь ?

" игра без определённого итога — то ли найдём, то ли нет."

ГВ>Правильно. Цепочку с Грэмом я сюда добавил, чтобы отсечь возможный перенос "опасности" на его компанию. Здесь я напомню тебе, что компания Грэма — самый, что ни на есть бизнес.

В том клочке бизнеса, где люди вроде Грехема, зависящие от самих себя, на стартапе можно использовать даже Лисп.

А как только проект перерастает во чтото более серьезное, то Лисп уже не представляет ценности.

I>>Лисп из этой формулы выпадает.

ГВ>Я тут формулы не увидел. Заклинание — да, а формулу — нет.

Ну попридирайся к словам

I>>Ага, и 50 лет Лиспу мешала эта формула.
I>>Почему же эта формула не мешала другим языкам ?

ГВ>Как видишь, в случае Грэма эта формула лиспу не помешала.

Это и ежу понятно. Лисп как был за пределами статпогрешности, так и остался

ГВ>>>Это единственный показатель, на самом деле.
I>>Это тавтология а не показатель.

ГВ>Ну, если ты считаешь, что Грэм не занимался бизнесом, то продолжать дискуссию бессмысленно. А если считаешь, то перечитай поскипанное.

Ну занимался он, что с того ? Зависимость его самого от него самого рассматривать будем ? Можешь развить эту идею, мне все равно

ГВ>Бизнес бывает разный (говоря по-русски: дела бывают разными, или же — люди делают разное). Я никак не воткнусь: почему ты не считаешь бизнес Грэма достойным упоминания? Это же пример мегауспешного бизнеса, если разобраться.

Согласно определению, это бизнес, но что толку ?

Где гарантия что этот опыт можно хоть как то распространить ?

Нет гарантии, на что указывает уже сам отказ Яхи от лиспа.

ГВ>Почему-то Грэм обошёлся без этой самой определённости.

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

ГВ>Реши, реши. Только прими во внимание, что Viaweb — это продукт, а Грэм тоже занимался бизнесом, при этом посмеиваясь над майнстримом. Вот прими во внимание эти условия, а потом докажи, что бизнес нуждается в майнстриме, ему не нужен лисп и т.п.

I>>Много больше, чем лисперов.

ГВ>Считал?

А что тут считать ? Это число прямо пропорционально объему сообщества при условии что нет принудительного регулирования.

I>>Ну ты и дал. Кто ж тебе неопределенность числом определит ? Это ж секрет философского камня

ГВ>Как тогда рисками управлять? "Здесь страшно, сюда не ходи!", так, что ли?

Вобщем то да. Величина риска это некое среднепотолочное значение.

I>>Естественно. Бизнес работает с тем что есть, а не с тем, что удобно.

ГВ>Бизнес бывает разный.

Бывает. Ограбить в подъезде — тож бизнес. Здесь работают с тем, что удобно.

I>>Лисп в бизнес за 50 лет и не попал.

ГВ>Это уже апофеоз.

Грэм, надо думать, не бизнесмен.

Грехем это исключение из правила, не более того.

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

FR>>>Ценность лиспа равна возможности привлекать высококвалифицированных хорошо мотивированных специалистов.

I>>Ну то есть нулю

FR>Если такие специалисты не нужны то да

"возможности привлекать высококвалифицированных хорошо мотивированных специалистов"

1 нет надобности, нет возможности = 0
2 нет надобности, есть возможность = 0
3 есть надобность, нет возможности = 0
4 есть надобность, есть возможность >0

В случае с яхой был случай 3, о чм Грехем и поведал.

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

Я выделил главное.

>>Этот вот аргумент весит намного больше, чем все разговоры относительно недоступности специалистов.
I>Этот аргумент ровно ничего не весит.

Здесь я говорил про "goog old-fashioned times". Если ты платишь за каждый час машинного времени, производительность — весьма даже аргумент.

I>В том клочке бизнеса, где люди вроде Грехема, зависящие от самих себя, на стартапе можно использовать даже Лисп.
I>А как только проект перерастает во чтото более серьезное, то Лисп уже не представляет ценности.

О-о-о! Наконец-то мне удалось из тебя выдавить хоть какую-то связность тезисов. Долго, но для бешеной собаки... Итак, лисп всё же может иметь ценность, даже по словам Ikemefula, олицетворяющего в наших кругах "большой серьёзный бизнес".

ГВ>>Как видишь, в случае Грэма эта формула лиспу не помешала.
I>Это и ежу понятно. Лисп как был за пределами статпогрешности, так и остался

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

ГВ>>Ну, если ты считаешь, что Грэм не занимался бизнесом, то продолжать дискуссию бессмысленно. А если считаешь, то перечитай поскипанное.
I>Ну занимался он, что с того ? Зависимость его самого от него самого рассматривать будем ? Можешь развить эту идею, мне все равно

А больше ничего не требуется. Грэм занимался бизнесом, лиспу в бизнесе место есть, дискутировать больше не о чем.

ГВ>>Бизнес бывает разный (говоря по-русски: дела бывают разными, или же — люди делают разное). Я никак не воткнусь: почему ты не считаешь бизнес Грэма достойным упоминания? Это же пример мегауспешного бизнеса, если разобраться.
I>Согласно определению, это бизнес, но что толку ?

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

I>Где гарантия что этот опыт можно хоть как то распространить ?

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

I>Нет гарантии, на что указывает уже сам отказ Яхи от лиспа.

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

ГВ>>Почему-то Грэм обошёлся без этой самой определённости.

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

Ну вот, видишь. Достаточно было признать, что то, чем занимался Грэм с Viaweb, называется "бизнес" — сразу всё становится на свои места. Вот тебе и один из критериев применимости опыта Грэма.

ГВ>>Реши, реши. Только прими во внимание, что Viaweb — это продукт, а Грэм тоже занимался бизнесом, при этом посмеиваясь над майнстримом. Вот прими во внимание эти условия, а потом докажи, что бизнес нуждается в майнстриме, ему не нужен лисп и т.п.
I>>>Много больше, чем лисперов.
ГВ>>Считал?
I>А что тут считать ? Это число прямо пропорционально объему сообщества при условии что нет принудительного регулирования.

У лиспа не такое уж и мелкое сообщество.

I>>>Лисп в бизнес за 50 лет и не попал.

ГВ>>Это уже апофеоз.

Грэм, надо думать, не бизнесмен.
I>Грехем это исключение из правила, не более того.

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

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

I>В том клочке бизнеса, где люди вроде Грехема, зависящие от самих себя, на стартапе можно использовать даже Лисп.

Обрати внимание на эту реплику. Здесь ты вплотную подобрался к главному: к роли людей в бизнесе.

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

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

Почему-то это не помешало AutoDesk-у встроить в свой AutoCAD диалект лиспа. Ещё можно назвать, пожалуй, Emacs. Так что, как видишь, лисп в современном мире — обыденное дело.

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

ГВ>Почему-то это не помешало AutoDesk-у встроить в свой AutoCAD диалект лиспа. Ещё можно назвать, пожалуй, Emacs. Так что, как видишь, лисп в современном мире — обыденное дело.

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

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

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

>>>Этот вот аргумент весит намного больше, чем все разговоры относительно недоступности специалистов.
I>>Этот аргумент ровно ничего не весит.

ГВ>Здесь я говорил про "goog old-fashioned times". Если ты платишь за каждый час машинного времени, производительность — весьма даже аргумент.

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

I>>В том клочке бизнеса, где люди вроде Грехема, зависящие от самих себя, на стартапе можно использовать даже Лисп.
I>>А как только проект перерастает во чтото более серьезное, то Лисп уже не представляет ценности.

ГВ>О-о-о! Наконец-то мне удалось из тебя выдавить хоть какую-то связность тезисов. Долго, но для бешеной собаки... Итак, лисп всё же может иметь ценность, даже по словам Ikemefula, олицетворяющего в наших кругах "большой серьёзный бизнес".

Да, а микроскопом можно гвоздь забить. Так и с Лиспом.

ГВ>А никто не пытался опровергать, что распространённость лиспа находится на уровне этой самой статпогрешности. Hackers (в позитивном смысле) — это тоже статпогрешность, кстати. Иначе бы они не считались "хорошими", а были бы "обычными".

А на лиспе других смысла не стоит нанимать.

I>>Ну занимался он, что с того ? Зависимость его самого от него самого рассматривать будем ? Можешь развить эту идею, мне все равно

ГВ>А больше ничего не требуется. Грэм занимался бизнесом, лиспу в бизнесе место есть, дискутировать больше не о чем.

См выше про микроскоп.

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

Ну то есть надо еще поискать тот бизнес куда можно впихнуть Лисп.

I>>А что тут считать ? Это число прямо пропорционально объему сообщества при условии что нет принудительного регулирования.

ГВ>У лиспа не такое уж и мелкое сообщество.

Относительно языков вроде С++, джавы, С# он за гранью статпогрешности.

Питон, перл, руби — каждый из них хотя и экзотика, тем не менее имеют сообщетво посильнее Лиспа.

I>>Грехем это исключение из правила, не более того.

ГВ>О каких правилах речь? За 50 лет своего существования лисп прекрасно "обжился в бизнесе" (воспользуюсь оборотами жёлтых газет), пример Грэма это отлично доказывает.

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

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

I>>В том клочке бизнеса, где люди вроде Грехема, зависящие от самих себя, на стартапе можно использовать даже Лисп.

ГВ>Обрати внимание на эту реплику. Здесь ты вплотную подобрался к главному: к роли людей в бизнесе.

У нас с тобой разные взгляды на это главное.

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

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

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

ГВ>Почему-то это не помешало AutoDesk-у встроить в свой AutoCAD диалект лиспа. Ещё можно назвать, пожалуй, Emacs. Так что, как видишь, лисп в современном мире — обыденное дело.

Да, можно ажно десяток проектв крупных назвать, очень круто

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

ГВ>...что, в общем, заставляет усомниться в том, что действительная распространённость лиспа близка к статпогрешности. Следовательно, я поторопился, говоря здесь:

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

Ага, сходи на сайты где вакансии разложены да посмотри. Я пока ни одной не нашел

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

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

ГВ>>...что, в общем, заставляет усомниться в том, что действительная распространённость лиспа близка к статпогрешности. Следовательно, я поторопился, говоря здесь:

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

I>Ага, сходи на сайты где вакансии разложены да посмотри. Я пока ни одной не нашел

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

Исправленому верить, накосячил с клиподм

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

I>Ага, сходи на сайты где вакансии разложены да посмотри. Я пока ни одной не нашел

Плохо искал: http://www.work.ua/jobs/548293/ Датирована 26/05/2010.

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

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

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

I>>>В том клочке бизнеса, где люди вроде Грехема, зависящие от самих себя, на стартапе можно использовать даже Лисп.
ГВ>>Обрати внимание на эту реплику. Здесь ты вплотную подобрался к главному: к роли людей в бизнесе.
I>У нас с тобой разные взгляды на это главное.

Я уж догадался.

Приватбанк, крупнейший розничный банк Украины ищет лисповиков: http://rabota.ua/company203681/vacancy4401282?utm_source=jooble&utm_medium=cpc&utm_campaign=specialists

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

ГВ>>Здесь я говорил про "goog old-fashioned times". Если ты платишь за каждый час машинного времени, производительность — весьма даже аргумент.
I>Как бы да. Но почему то другим тормозам производительность не помешала.

Какие именно языки ты имеешь в виду?

I>>>В том клочке бизнеса, где люди вроде Грехема, зависящие от самих себя, на стартапе можно использовать даже Лисп.
I>>>А как только проект перерастает во чтото более серьезное, то Лисп уже не представляет ценности.
ГВ>>О-о-о! Наконец-то мне удалось из тебя выдавить хоть какую-то связность тезисов. Долго, но для бешеной собаки... Итак, лисп всё же может иметь ценность, даже по словам Ikemefula, олицетворяющего в наших кругах "большой серьёзный бизнес".

I>Да, а микроскопом можно гвоздь забить. Так и с Лиспом.

Да, я совершенно согласен с тем, что лисп — весьма неплохой язык.

ГВ>>А никто не пытался опровергать, что распространённость лиспа находится на уровне этой самой статпогрешности. Hackers (в позитивном смысле) — это тоже статпогрешность, кстати. Иначе бы они не считались "хорошими", а были бы "обычными".
I>А на лиспе других смысла не стоит нанимать.

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

ГВ>>Толк здесь тот, что дальнейшие утверждения нужно перестраивать в зависимости от характеристик самого бизнеса.
I>Ну то есть надо еще поискать тот бизнес куда можно впихнуть Лисп.

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

I>>>А что тут считать ? Это число прямо пропорционально объему сообщества при условии что нет принудительного регулирования.
ГВ>>У лиспа не такое уж и мелкое сообщество.
I>Относительно языков вроде С++, джавы, С# он за гранью статпогрешности.

Честно сказать, не знаю. Мне на это плевать, вообще-то.

I>Питон, перл, руби — каждый из них хотя и экзотика, тем не менее имеют сообщетво посильнее Лиспа.

См. выше.

I>>>Грехем это исключение из правила, не более того.
ГВ>>О каких правилах речь? За 50 лет своего существования лисп прекрасно "обжился в бизнесе" (воспользуюсь оборотами жёлтых газет), пример Грэма это отлично доказывает.
I>Прекрасно обжился это когда хотя бы каждый десятый проект на нем создается. Это гарантирует что лет черз 10 будт спецы хотя бы для поддержки проектов.

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

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

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

I>>Ага, сходи на сайты где вакансии разложены да посмотри. Я пока ни одной не нашел

ГВ>Плохо искал: http://www.work.ua/jobs/548293/ Датирована 26/05/2010.

Я пару сайтов проверил.

Только что погуглил в рунете немного на тему работы, вакансий, проектов — Lisp начисто сливает даже экзотике вроде perl, python. Самый лучший результат, что удалось выбить — 9млн результатов, при этом джава, C# и C++ уходят за 60-70 млн.

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

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

ГВ>>>Здесь я говорил про "goog old-fashioned times". Если ты платишь за каждый час машинного времени, производительность — весьма даже аргумент.
I>>Как бы да. Но почему то другим тормозам производительность не помешала.

ГВ>Какие именно языки ты имеешь в виду?

Вот кобол тот же. А вообще лет 15-20 назад производительность уже точно не имела значения. Например первая джава была жутким тормозом и тем не менее основательно потеснила более шустрый С++. Перл, Питон первых версий так же были тормозами

Вобщем лиспу все время что то мешало. Даже когда перформанс перстал определять что либо, у лиспа все равно какие то проблемы — слишком много диалектов, слабая читабельность, отсутствие инструментов

ГВ>>>О-о-о! Наконец-то мне удалось из тебя выдавить хоть какую-то связность тезисов. Долго, но для бешеной собаки... Итак, лисп всё же может иметь ценность, даже по словам Ikemefula, олицетворяющего в наших кругах "большой серьёзный бизнес".

I>>Да, а микроскопом можно гвоздь забить. Так и с Лиспом.

ГВ>Да, я совершенно согласен с тем, что лисп — весьма неплохой язык.

Это не имеет значения, глядя на 40 лет кобола.

I>>А на лиспе других смысла не стоит нанимать.

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

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

Я ж сказал — за гранью статпогрешности.

I>>Ну то есть надо еще поискать тот бизнес куда можно впихнуть Лисп.

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

С++, Джава, С№ не надо никуда впихивать. Бизнес сам приходит и просит именно это.

I>>Прекрасно обжился это когда хотя бы каждый десятый проект на нем создается. Это гарантирует что лет черз 10 будт спецы хотя бы для поддержки проектов.

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

Презрение это твоя проекция.

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

ГВ>>>>Здесь я говорил про "goog old-fashioned times". Если ты платишь за каждый час машинного времени, производительность — весьма даже аргумент.
I>>>Как бы да. Но почему то другим тормозам производительность не помешала.
ГВ>>Какие именно языки ты имеешь в виду?
I>Вот кобол тот же. А вообще лет 15-20 назад производительность уже точно не имела значения. Например первая джава была жутким тормозом и тем не менее основательно потеснила более шустрый С++. Перл, Питон первых версий так же были тормозами

I>Вобщем лиспу все время что то мешало. Даже когда перформанс перстал определять что либо, у лиспа все равно какие то проблемы — слишком много диалектов, слабая читабельность, отсутствие инструментов

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

ГВ>>>>О-о-о! Наконец-то мне удалось из тебя выдавить хоть какую-то связность тезисов. Долго, но для бешеной собаки... Итак, лисп всё же может иметь ценность, даже по словам Ikemefula, олицетворяющего в наших кругах "большой серьёзный бизнес".

I>>>Да, а микроскопом можно гвоздь забить. Так и с Лиспом.
ГВ>>Да, я совершенно согласен с тем, что лисп — весьма неплохой язык.
I>Это не имеет значения, глядя на 40 лет кобола.

Не понял.

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

ГВ>>>>Толк здесь тот, что дальнейшие утверждения нужно перестраивать в зависимости от характеристик самого бизнеса.
I>Я ж сказал — за гранью статпогрешности.

Снова не врубился. Ты можешь не так туманно выражаться?

I>>>Ну то есть надо еще поискать тот бизнес куда можно впихнуть Лисп.
ГВ>>Это справедливо по отношению к любому языку программирования, лисп — не исключение.
I>С++, Джава, С№ не надо никуда впихивать. Бизнес сам приходит и просит именно это.

Повторяю, бизнес бывает разный.

I>>>Прекрасно обжился это когда хотя бы каждый десятый проект на нем создается. Это гарантирует что лет черз 10 будт спецы хотя бы для поддержки проектов.
ГВ>>Ой, ну извините... Ладно, продолжай демонстрировать всяческое презрение к лиспу дальше, у тебя это хорошо получается.
I>Презрение это твоя проекция.

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

Космический масштаб, однако...

	От:	abdul.zycor
	Дата:	28.01.10 23:16
	Оценка:

	От:	Niemand
	Дата:	29.01.10 00:13
	Оценка:

	От:	TarasCo
	Дата:	29.01.10 06:29
	Оценка:

	От:	frogkiller
	Дата:	29.01.10 06:42
	Оценка:	2 (2) +3 -5

	От:	Pavel Dvorkin
	Дата:	29.01.10 07:17
	Оценка:	2 (2) +2 -5

От:	dr.Chaos	Украшения HandMade
Дата:	29.01.10 08:18
Оценка:	+1 -2

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	29.01.10 10:58
Оценка:	+1 -6

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	29.01.10 19:26
Оценка:

	От:	zaufi
	Дата:	29.01.10 21:29
	Оценка:	2 (2) +1 -1

От:	alexdev	http://alexdev-ru.livejournal.com
Дата:	31.01.10 11:53
Оценка:

	От:	труженик села
	Дата:	31.01.10 15:01
	Оценка:

От:	denisko	http://sdeniskos.blogspot.com/
Дата:	01.02.10 03:24
Оценка:	-3

	От:	CreatorCray
	Дата:	01.02.10 15:20
	Оценка:	3 (1) +1

От:	VladD2	www.nemerle.org
Дата:	02.02.10 01:45
Оценка:

	От:	Cyberax
	Дата:	03.02.10 12:43
	Оценка:	4 (3) +1

	От:	Mr.Cat
	Дата:	30.01.10 05:27
	Оценка:

	От:	IID
	Дата:	30.01.10 07:49
	Оценка:

	От:	skeptik_
	Дата:	30.01.10 11:24
	Оценка:	+2

	От:	LuciferSaratov
	Дата:	03.02.10 18:18
	Оценка:	+1

	От:	Sheridan
	Дата:	05.02.10 16:12
	Оценка:	1 (1) +1

От:	EreTIk	EreTIk's Box
Дата:	05.02.10 18:23
Оценка:	2 (1)

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	05.02.10 21:49
Оценка:	+4

От:	Mamut	http://dmitriid.com
Дата:	08.02.10 13:58
Оценка:	1 (1)

От:	koandrew	http://thingselectronic.blogspot.ca/
Дата:	17.02.10 16:56
Оценка:

От:	ollv	https://youtu.be/DQDoYs6wHoo
Дата:	18.02.10 00:06
Оценка:

От:	max-maxtor	www.rsdn.ru
Дата:	26.05.10 11:01
Оценка:

	От:	vladimir.vladimirovich
	Дата:	09.06.10 18:21
	Оценка: