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

FR>Так freeze же вроде родная юниксовская утилита, нам до py2exe пришлось свою ваять чтобы полную сборку в один exe со всеми нужными библиотеками делать.

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

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

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

А сборку с полной статической линковкой нельзя разве сделать? У нас сначала была полная статическая линковка потом, зависимость только от python23.dll который лежал рядом с exe.

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

VD>Здравствуйте, kaa.python, Вы писали:

VD>>>C++ уже не будет мэйнстримом.
KP>>да он и сейчас, вроде как не мэйнстрим.

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

Именно, но так, но есть как говорится области, где пока ему нет альтернативы (если не считать, возможно, OCaml).

VD>Возможно было бы не плохо если появился бы язык нового поколения поддерживающий как современные стили программирования (ООП, ФП, МП), так и имеющий полноценный низкоуровневый режим (битодробильный). Но на мой взгляд этот язык уж точно не должен быть похож ни на Ди, ни на С++. Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.

Обработка изображений и видео в реальном времени, на ПК + embedded платформах.
"Обработка" читай распознавание\ интеллектуальная обработка, когда обрабатывают на биты пикселей, а информацию, которую они несут.
И если задумаетесь, что вот вам прямо сейчас будет необходимо проектировать систему для решения задач именно этой области, то вряд ли предложите что-то другое, окромя С++.

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

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

Не только. Есть довольно много задач, которые решать без C/C++ будет крайне затруднительно. Просто на нем перестали писать все что ни попадя, что безусловно хорошо.

Mr.Cat,

MC>Эх, не думаю... Все фишки CL и схемы уже расхватали дизайнеры других языков. Ну или почти все (Где еще есть динамическая область видимости переменных? Хотя это, конечно, всего лишь маленький кусочек сахара).

Динамическая область видимости есть ещё в StringTemplate — неплохой язык для построения генераторов.

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

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

Поэтому сначала появляется версия 1.0 по дешевому сценарию, набиваются шишки и следует переход к более дорогой v2.0 (и так далее )

Здравствуйте, <Аноним>, Вы писали:

А>А может на JavaScript будем драйверы писать?

Насмешил, подобные вопросы рассматриваются вполне серьезно

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

VD>Возможно было бы не плохо если появился бы язык нового поколения поддерживающий как современные стили программирования (ООП, ФП, МП), так и имеющий полноценный низкоуровневый режим (битодробильный). Но на мой взгляд этот язык уж точно не должен быть похож ни на Ди, ни на С++. Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.

У C/C++ есть несколько очень больших преимуществ:

— не нужна VM (не считая статически подвязываемого C runtime);
— стабильность языка (ага, как раз то, что новые веяния впитываются в C/C++ достаточно медленно);
— чудовищное количество наработанного и используемого ПО (это миллиарды копий, вдумайтесь в это число — 10^9, вы хочите аргументов массой? Их есть у меня);
— все (AFAIK) более или менее широко используемые языки и системы имеют foreign-интерфейс с C (не Lisp, не Java, не .Net).

А остальные прогрессивные парадигмы благополучно плещутся в среде, которое создало ПО на C/C++. Вот такая вот идиллия.

И если учесть эти факторы, то кто там станет мейнстримом завтра — да какая, на фиг, разница? Программистов на C/C++ всегда было относительно немного — 10-15% от общей массы, не считая, — как ты это правильно заметил, — глюка начала 2000-х, когда "плюсовиками" называли себя все, кому не лень.

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

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

Pzz>>>А я, будь моя воля, выгнал бы нафиг всех писателей на C++. А знатоков "современного" C++ банил бы еще на стадии чтения ихних резюмов

ГВ>>За что, боярин?!

Pzz>За дело!

Надо мужикам рассказать: Певзнер за безделье не забанит! Добрый боярин!

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

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

Чем, кроме оптимизации, функтор лучше интерфейса?

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

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

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

E>Чем, кроме оптимизации, функтор лучше интерфейса?

Интерфейс (в смысле абстракного понятия), требующий фуктора или, например, boost::function будет гораздо проще в определении и в использовании, чем интерфейс, требующий интерфейса (в смысле интерфейсного класса). Сравни, например, Java Runnable и boost::thread.

Чтобы создать поток, с помощью Runnable, нам нужно определить свой собственный класс, унаследованный от Runnable, потом определить у него метод run(), а после этого создать объект этого класса и передать его в класс Thread, и — наконец-то — поток запустится.

Для сравнения, в boost::thread создание потока, исполняющего любую наперед существующюю функции или метод класса или объекта функтора, является тривиальной операцией:

boost::thread thr(&my_arbitrary_function);

И все! Никаких дополнительных интерфейсов и классов, ничего не надо реализовывать, и никаких ненужных сущностей создавать не надо. Все предельно кратко и лаконично.

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

Pzz>А я, будь моя воля, выгнал бы нафиг всех писателей на C++. А знатоков "современного" C++ банил бы еще на стадии чтения ихних резюмов

IMHO, это слишком радикально. Вполне достаточно потребовать и добиться того, чтобы они не писали неоправданно сложно...

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

A>И все!

Не, еще не все. Еще есть лямбды с С++0Х

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

A>И все! Никаких дополнительных интерфейсов и классов, ничего не надо реализовывать, и никаких ненужных сущностей создавать не надо. Все предельно кратко и лаконично.

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

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

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

Pzz>>А я, будь моя воля, выгнал бы нафиг всех писателей на C++. А знатоков "современного" C++ банил бы еще на стадии чтения ихних резюмов

E>IMHO, это слишком радикально. Вполне достаточно потребовать и добиться того, чтобы они не писали неоправданно сложно...

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

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

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

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

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

MC>Не совсем то, конечно, но Erlang вроде — как раз пример ФП + битодробления...

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

VD>>Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.
MC>Массы вроде бы его приняли.

Где? Что-то эти массы не видно в микроскоп.

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

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

FR>Выше замени Ди на немерле

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

FR>Для масс D как раз и хорош, так же как и шарп.

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

А про массы просто смешно слушать. Где они?

Здравствуйте, VladD2, Вы писали:
VD>Ты наверно говоришь о библиотеке позволяющей разбирать бинарные структуры данных.
Да.

VD>Насколько я знаю, она написана не на Эрлаге.
Ессно. Я имел в виду, что "бинарный" паттерн-матчинг там — довольно удобная штука. Просто неправильно понял, что Вы имели в виду под "битодроблением".

VD>Где? Что-то эти массы не видно в микроскоп.
Смотря с чем сравнивать. Если с C++\C# — то да, до их популярности он не дотягивает.
Тем не менее, насколько я понимаю, он уже довольно широко, вон даже на сайтах, типа hh, стали появляться вакансии erlang-разработчиков (это если сравнивать с D, CL и т.п.)

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

Pzz>>>А я, будь моя воля, выгнал бы нафиг всех писателей на C++. А знатоков "современного" C++ банил бы еще на стадии чтения ихних резюмов
E>>IMHO, это слишком радикально. Вполне достаточно потребовать и добиться того, чтобы они не писали неоправданно сложно...
Pzz>Это во-первых невозможно никак поенфорсить, во-вторых они гордятся своей способностью писать с особым преподвывертом, в третьих некоторые вещи, которых надо стыдиться как ночного недержания мочи, у нис считаются хорошим тоном.

Неужто все, кто "знает современный C++" этакое творят?