C#

>Ты меня переоцениваешь - это инерция целой индустрии :) И не только инерция - я привел и достоинства Си/Си++

Нет. Инерцией индустрии это было пару-тройку лет назад. Сегодня индустрия ставит на Java :)

>А сам я в последнее время на Python пишу больше, чем на Си++

А я, вот, с Си++ ушёл лет 5..6 назад. Проработав до этого на нём около 7 лет. Ушёл сперва в Perl, потом в PHP, сейчас, вот, одной ногой в Java. Хотя тоже периодически щупаю Python. За последние года четыре на Си++ только бенчмарки писал :)

>Но насколько 1 пример показателен?

Время покажет :) Например, когда я смотрел, как дела идут у "плюснутого" сервера WoW - там все форумы были забиты поисками утечек памяти, отлавливанием вечных null pointer и т.п. Кстати, об отладке. Java, выдав иксепшн на рабочем сервере чётко диагностирует место ошибки. С точностью до строки. И после этого ещё продолжает работать (в самом худшем случае падает тред одной сетевой задачи). Т.е. садишься просто вечером, листаешь лог stdout/stderr и выискиваешь ошибки. И тут же их исправляешь.

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

ИМХО, такая работа столько усилий потребует... Тема диссертации на каком-нибудь психологическом факультете :D

> А, чего там мелочиться. Вот, иду на секунию и вывожу список свежих _уязвимостей_ с переполнениями: - WinRAR - Gimp - LibTIFF - mpg123 - OpenLDAP - MySQL

И чё, все они обусловлены использованием указателей? Нет, чё, правда? А как же sprintf?

>>Ты меня переоцениваешь - это инерция целой индустрии :) И не только инерция - я привел и достоинства Си/Си++

>Нет. Инерцией индустрии это было пару-тройку лет назад. Сегодня индустрия ставит на Java :)

Да? Именно на Java, не на С# ? Откуда данные ? (сам я уже несколько лет не слежу за тенденциями)

>>А сам я в последнее время на Python пишу больше, чем на Си++

>А я, вот, с Си++ ушёл лет 5..6 назад. Проработав до этого на нём около 7 лет. Ушёл сперва в Perl, потом в PHP

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

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

В Си для такого нужно сделать скрипт для gdb, обработчик сигнала и запустить прогу под gdb.

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

Автор быдлопесатель на былоизыке Cглюк http://www.codenet.ru/progr/cpp/Sharp-Java.php

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

>Автор быдлопесатель на былоизыке Cглюк

Автора не знаю, произведения не читал, но одобряю.

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

Сильно сомневаюсь. Java - отнюдь не новый язык. Очнитесь, ему уже более 10 лет. А преимуществ в сфере осестроения так и не показал. Это не я говорю, что решающих преимуществ нет. Это ПРАКТИКА показала. А это уже многое значит :)

> php... обезьяна... безопасный код... многочисленные защиты от дурака... Бугага!!!! :))) Это несовместимые слова. Ну может разве если первые 2 :))

И в чём же несовместимость? Или только юродствовать умеем?

> Большое достоинство. Но ассемблер ещё менее требователен был :D

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

> Безусловно. Пример был, правда, с акцентом не на 1С, а на противостояние ассемблера и Си :)

Чукча писатель?

>А преимуществ в сфере осестроения так и не показал. Это не я говорю, что решающих преимуществ нет. Это ПРАКТИКА показала.

Практика показала, что писать ОС на Java для машины с 128-512Мб памяти нет смысла. Вот в 2007-2008 16Гб на среднюю машину станет нормой, тогда и увидим расцвет ОСестроения на Java. Если Singularity не успеет на C# раньше ;)

>>А преимуществ в сфере осестроения так и не показал. Это не я говорю, что решающих преимуществ нет. Это ПРАКТИКА показала.

>Практика показала, что писать ОС на Java для машины с 128-512Мб памяти нет смысла.

Единственное, что практика показала, это что ОСи на Java никому не нужны - всех устраивают существующие, на Си.

IIRC проект Jexe работал в 16М лет 8-10 назад.

> Единственное, что практика показала, это что ОСи на Java никому не нужны - всех устраивают существующие, на Си.

> IIRC проект Jexe работал в 16М лет 8-10 назад.

Проблема тут IMHO вот в чём. Java находится в положении вечнодогоняющего. Т.е. оси на C тоже не стоят на месте, они тоже развиваются. Но при этом всегда получается, что при одинаковой мощности ось на java будет тормознее и требовательнее к памяти. Так было 5 лет назад, так есть сейчас и так будет через 5 лет. Потому что РЕШАЮЩИХ преимуществ у жабы - НЕТ. А решающих недостатков - сколько угодно.

>Потому что РЕШАЮЩИХ преимуществ у жабы - НЕТ.

Если _для тебя_ их нет - то не надо об этом так громко кричать. Это показывает твою ограниченность. Решающие преимущества есть в тех или иных областях практически у любого языка. В том числе есть они и у Java.

По поводу ресурсов, кстати.

Мобильники с J2ME - это что, дикие ресурсы? Гигабайты памяти?

Покажи мне любую игрушку на Си/Си++, которая пойдёт с одного бинарника и на симбиане, и на "безоперационных" сименсах, и на КПК...

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

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

...

Впрочем, спорьте, не спорьте, а Java сейчас весьма плотно обошла конкурентов... Не является для вас весомым количество вакансий - тогда посмотрите на Фрешмит или Сорурсфорж. Java сейчас на первом месте по числу проектов. А ещё 5 лет назад вдвое с лишним уступала одному только Си и почти вдвое - Си++.

> Если _для тебя_ их нет - то не надо об этом так громко кричать. Это показывает твою ограниченность. Решающие преимущества есть в тех или иных областях практически у любого языка. В том числе есть они и у Java.

А ты не кричи. Ты их перечисли :)

> Мобильники с J2ME - это что, дикие ресурсы? Гигабайты памяти?

Я, вообще-то, говорил про ОС для PC. Но ты опять в пылу всё забыл :)

> с -- таки подмножество с++

почитай http://david.tribble.com/text/cdiffs.htm и подумай

>>Потому что РЕШАЮЩИХ преимуществ у жабы - НЕТ.

>Если _для тебя_ их нет - то не надо об этом так громко кричать.

Анонимный брат говорил об ОСестроении, в котором у Java решающих преимуществ и в самом деле нет (пока?).

> Покажи мне любую игрушку на Си/Си++, которая пойдёт с одного бинарника и на симбиане, и на "безоперационных" сименсах, и на КПК...

Если лезть совсем уж глубоко в историю, то реализация Java в виде виртуальной машины - признанная (тихо и нехотя) ошибка. Тогда уже была технология, обеспечивавшая переносимые бинари для любого языка. В этих бинарях хранилось промежуточное представление компилятора - после семантического анализа, но до генерации кода. За счет этого бинари получались компактными, а JIT-компилятор мог использовать все те же техники генерации кода и оптимизации, что и обычные компиляторы (и уровень производитльности, который достигнут Java сейчас, был бы уже 10 лет назад).

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

Виртуальные машины - зло.

> Виртуальные машины - зло.

А почему собственно зло? Разве плохо абстрагироваться от платформы?

>> Виртуальные машины - зло.

>А почему собственно зло?

Ну, если я это неубедительно объяснил постом выше, тогда ой...

> Разве плохо абстрагироваться от платформы?

Абстрагироваться - хорошо, если уровень абстракции подходящий. Только потом (или с самого начала) в каждую виртуальную машину встраивается JIT, которому приходится вытаскивать информацию об оптимизации из байт-кода, а не графа внутреннего представления компилятора. Работу JIT это не облегчает и проще он от этого не становится. И, внимание, вопрос - а нахнадо? Я понимаю, когда VM клепается для динамического языка, разрабатываемого группой добровольцев (Python). Но для Java, за которой стоял Sun? Почему не тот подход, о котором я писал выше? Потому что NIH?

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

Обалдеть! Китайский забыл!

> Java сейчас на первом месте по числу проектов. А ещё 5 лет назад вдвое с лишним уступала одному только Си и почти вдвое - Си++.

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

У меня каталог в 30 тыс. записей. Почему я не могу из него удалить файлы по маске через rm? "Слишком большой список аргументов!"

ls | xargs rm

>ls | xargs rm

Угу. Осталась сущая мелочь. Научить работать в таком духе revdep-rebuild...

>В университетах программированию стали учить на Java, вот выпускники и выбирают ее.

Угу. И этим выпускникам сразу зарплату в $1,5..2к выдают...

Вот, первые две страницы с rabota.ru (Москва, запрос - "программист"):

MSSQL - 800
Java - 1500..2000
1C - 1000
Delphi+Interbase - 2000
VB.Net - 800
.NET - 2300
PHP - 1300
Java - 800-1000
PHP - 1000..1500
C++ - 1500
PL/SQL - 2000...3000
Java - 2000..2500
PHP - 1400..1500
C# - 1500..2000
VB.NET или C# - 1600..1700
Java - 1500..2700
Java - 1500..2000
C# - 1400..1800
Perl - 2000
Java - 2000
PHP - 700

>>В университетах программированию стали учить на Java, вот выпускники и выбирают ее.

>Угу. И этим выпускникам сразу зарплату в $1,5..2к выдают...

Я говорил о freshmeat и sourceforge.

В твоем списке, кстати, специалисты по .NET нужны почти так же, как и по Java. В связи с чем и вопрос - а правда, что индустрия делает ставку именно на Java, а не .NET ;)

> Научить работать в таком духе revdep-rebuild...

source is open.

Хм, что-то я не замечал таких проблем с revdep-rebuild.

>Хм, что-то я не замечал таких проблем с revdep-rebuild.

# revdep-rebuild -p
Configuring search environment for revdep-rebuild

Environment mismatch from previous run, deleting temporary files...

Checking reverse dependencies...

Packages containing binaries and libraries broken by a package update
will be emerged.

Collecting system binaries and libraries... done.
(/root/.revdep-rebuild.1_files)

Collecting complete LD_LIBRARY_PATH... done.
(/root/.revdep-rebuild.2_ldpath)

Checking dynamic linking consistency...
/usr/bin/revdep-rebuild: line 402: /usr/bin/sed: Слишком длинный список аргументов
/usr/bin/revdep-rebuild: line 404: /usr/bin/cat: Слишком длинный список аргументов
/usr/bin/revdep-rebuild: line 404: /bin/egrep: Слишком длинный список аргументов
/usr/bin/revdep-rebuild: line 450: /usr/bin/cat: Слишком длинный список аргументов
/usr/bin/revdep-rebuild: line 450: /bin/egrep: Слишком длинный список аргументов
done.
(/root/.revdep-rebuild.3_rebuild)

Assigning files to ebuilds... Nothing to rebuild

Evaluating package order.../usr/bin/revdep-rebuild: line 583: /usr/bin/cat: Слишком длинный список аргументов/usr/bin/revdep-rebuild: line 583: /usr/bin/tr: Слишком длинный список аргументов
/usr/bin/revdep-rebuild: line 583: /usr/bin/sed: Слишком длинный список аргументов
done.
(/root/.revdep-rebuild.5_order)
/usr/bin/revdep-rebuild: line 623: /usr/bin/sed: Слишком длинный список аргументов
/usr/bin/revdep-rebuild: line 623: /usr/bin/tr: Слишком длинный список аргументов
/usr/bin/revdep-rebuild: line 623: /usr/bin/cat: Слишком длинный список аргументов

Dynamic linking on your system is consistent... All done.
/usr/bin/revdep-rebuild: line 631: /usr/bin/rm: Слишком длинный список аргументов
/usr/bin/revdep-rebuild: line 632: /usr/bin/rm: Слишком длинный список аргументов

>В твоем списке, кстати, специалисты по .NET нужны почти так же, как и по Java. В связи с чем и вопрос - а правда, что индустрия делает ставку именно на Java, а не .NET ;)

Учитывая, что MS делает ставку на .NET, удивительно, что спецы по .NET требуются так мало :)

Обалдеть, много же у тебя мусора наставлено!

>Обалдеть, много же у тебя мусора наставлено!

Так revdep-rebuild и предназначен, чтобы этот мусор разгребать. И не справляется с прямо задачей. Из-за, мать итить их - БУФЕРОВ :) А вы - указатели, указатели...

Вот на Java такой фигни не бывает. Использовать массивы виксированной длины там, где можно использовать списки - моветон. А длина списков - ограничена только оперативкой.

вообще для этого предназначен emerge --unmerge ;-)

> Вот на Java такой фигни не бывает.

Да, это бы ло бы решающее преимущество ОС на Java 8)

>вообще для этого предназначен emerge --unmerge ;-)

А он каким боком поможет-то? :) Тем более, пока всё собирался слепить скрипт, который тупо удаляет из либ всё, что не прописано в портеже, выйснилось, что на домашней машине система доросла до такого состояния, когда revdep-rebuild уже не срабатывает даже на вполне исправной системе. (вышеприведённый дамп - это с системы, которая два года переживала жуткие извращения, в т.ч. один раз копирование либ с live-cd :))

>В любом языке можно сделать while(1){} и греть проц до беспамятства. И что? Давайте теперь ещё скажем, что "loops are not safe".

В Ruby так и есть. Там вместо циклов итераторы рекомендуют использовать.

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

Что-то подобное (или я ошибаюсь?) недавно на ЛОРе уже упоминалось. Даже с сылкой на какой-то полурабочий/полуживой (и вроде как даже отечественный) проект... Не напомните?

Хотя что-то мне тогда в том проекте и не понравилось... (совсем склероз замучал - в голове "держится" только "хорошее", да и то не всё :))

А у вас весело.

Про указатели. То, что в java и c# мусоросборщики почему никто не вспомнил? Ай-ай-ай. Али не знаете, что указатели не просто так выбрасывают? Проще потому что. А ещё потому, что указатели нахер не нужны. У Дохлого выхода другого не было. Но в Си++ и без поитеров обойтись можна. А вот в Си -- попа треснет. Си вообще немногим лучше ассемблера. Собсна, он ассемблер и есть. Кроссплатформенный, типа.

И ваще. Люди, разрабатывающие языки -- люди умные (мацу-мота невщот).

Виртуальная машина им не угодила. Это кто там из явовцев стыдливо признался, что в.машина в яве была ошибкой? Они такую траву не курят, им подобный бред в башку не лезет.

Мне интересно а кореш анонимус что все в оси уперся, которые на ява написать низзя?У нас что каждый красноглазый должен ось свою напейсать?Типа 3 существующих козырных не хватает?

При чем тут ява и ось? Где об этом хоть слово в "16.08.2006 0:36:50" ? У тя вообще мысль была, или сказать хочется, а нечего?

Передай санитарам, что капельницу с димедролом тебе нужно отменить.

Для альтернативно одаренных это было по поводу anonymous (*) (21.07.2006 13:35:28) и иже с ними, где с какого то черта про оси рассказывается типа это 99% что делается из программ сейчас в мире?