LINUX.ORG.RU

Через год Java одержит окончательную победу над C, С++ и Visual Basic, показывают результаты последних исследований


0

0

На конференции IBM Solution вице-президент аналитической компании Evans Data Дженел Гарвин представила сенсационные данные. Результаты недавних исследований позволяют с большой долей уверенности предсказать, что в следующем году в США численность разработчиков, использующих Java, превысит численность тех, кто пользуется C, C++ или Visual Basic.

>>> Подробности

anonymous

Проверено:

Ответ на: комментарий от Antichrist

> Повторю аргументы из предыдущей мессаги: >1) компиляторы Фортрана до сих пор лучше всего оптимизирую численные >задачи. Более того, продвинутые представители сего славного семейства >способны так же АВТОМАТИЧЕСКИ параллелить многие алгоритмы (особенно >работу с векторами, матрицами, вырезками, и т.п.). >2) системы символьной алгебры очень хорошо заточены под генерацию >Фортранового кода и анализ/верификацию существующего Фортранового >кода. Уж больно язык для этой цели удобен... >3) огромное количество библиотек. Никто не заменит Lapack и CERNLIB. >

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

СтранниК

anonymous
()

ПРЕАМБУЛА:
Говорю о ПРИКЛАДНОМ программировании, одной из отличительных черт которого - некритичность задачи в отношении времени реакции системы.

ПРИМЕЧАНИЕ:
Java предназначена именно для ПРИКЛАДНОГО программирования и то, кто желает увидеть приличную СУБД на Java пусть встанет под холодный душ, глядишь постигнет дао или еще какую байду, или помрет от воспаления легких, да и хер с ним, таких мыслителей не жалко. А гражданин, пожелавший увидеть Doom на Java пусть меняет род занятий - компьютеры ему запрещены по медицинским противопоказаниям(за подробностями - к психиатору).

ФАБУЛА:
Блядь! Блядь! Сколько же надо по бестолковке бить, что бы стала понятна простейшая мысль: БЕЗРАЗЛИЧНО НА ЧЕМ РЕАЛИЗОВЫВАТЬ ЗАДАЧУ, если ты укладываешься в сроки, деньги и ТЗ. ПОХЕРУ! Java, C/C++/C#, Progress, Informix или любой другой 4GL, VB, хаскел или хераскел. БЕЗРАЗЛИЧНО! Рассуждения о "правильной" или "неправильной" струкуре языка - это прерогатива кафедральных теоретиков, НИКОГДА НЕ РАБОТАВШИХ НА РАНОК СОФТА. "Наследования, функторы - пиши сука!". Приладной софт - это много правильно работающего кода. 5-10-20 мегабайт исходного текста. Когда распечатанный на ленточном принтере текст проекта достает чуть не до плеча. Все. Правильно работающий код можно написать на любом языке, это, надеюсь, сомнений не вызвает?
Я вспоминаю своих преподавателей, с которыми в студенчестве работал на кафедре - профессионалы, очень умные люди. Но если бы кто-то из них рискнул со своим подходом к разработке программного обеспечения вылезти за пределы кафедры - сожрали бы в момент! Подход не тот. И сейчас я вижу примерно такие же рассуждения здесь. Админы, что ли о разработке софта рассуждать взялись? Не надо. У админа есть своя область приложения его умений, просторная, как приполярная тундра.
И если теоретик появится посреди такого проекта и начнет говорить, что язык, на котором проект пишется использует плохую модель наследования, то пусть не удивляется, когда схлопочет по репе, потому, что у разработчиков хватает дел и без теоретиков от программирования.


Полуденный Бес

anonymous
()
Ответ на: комментарий от dvb

Для dvb от СтранниКа

>Perl совсем не такой тормоз, как обычно про него думают. Да и >не так уж много задач, на которых время исполнения, увеличенное >в 2-4 раза ( Perl vs C ) - причина для расстройства. А вот время >разработки на Perl-е в разы быстрее, чем на других основных языках. >Поэтому на нем очень удобно быстро писать и обкатывать прототипы >программных систем, и особенно быстро, если вспомнить количество >готовых модулей. А уж разбирать текстовые данные или логи .... :) > Ну наконец-то здравые мысли появились и без матюков. Действительно надо ценить свое время и разбирать логи на java или "С" наверно надо быть мазохистом.

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

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

Недавно вот видел выражение очень понравилось: "Власть развращает, а абсолютная власть развращает абсолютно"

Думаю это касается и языков программирования.

СтранниК

anonymous
()

ПРЕАМБУЛА:
Говорю о ПРИКЛАДНОМ программировании, одной из отличительных черт которого - некритичность задачи в отношении времени реакции системы.

ПРИМЕЧАНИЕ:
Java предназначена именно для ПРИКЛАДНОГО программирования и то, кто желает увидеть приличную СУБД на Java пусть встанет под холодный душ, глядишь постигнет дао или еще какую байду, или помрет от воспаления легких, да и хер с ним, таких мыслителей не жалко. А гражданин, пожелавший увидеть Doom на Java пусть меняет род занятий - компьютеры ему запрещены по медицинским противопоказаниям(за подробностями - к психиатору).

ФАБУЛА:
Блядь! Блядь! Сколько же надо по бестолковке бить, что бы стала понятна простейшая мысль: БЕЗРАЗЛИЧНО НА ЧЕМ РЕАЛИЗОВЫВАТЬ ЗАДАЧУ, если ты укладываешься в сроки, деньги и ТЗ. ПОХЕРУ! Java, C/C++/C#, Progress, Informix или любой другой 4GL, VB, хаскел или хераскел. БЕЗРАЗЛИЧНО! Рассуждения о "правильной" или "неправильной" струкуре языка - это прерогатива кафедральных теоретиков, НИКОГДА НЕ РАБОТАВШИХ НА РАНОК СОФТА. "Наследования, функторы - пиши сука!". Приладной софт - это много правильно работающего кода. 5-10-20 мегабайт исходного текста. Когда распечатанный на ленточном принтере текст проекта достает чуть не до плеча. Все. Правильно работающий код можно написать на любом языке, это, надеюсь, сомнений не вызвает?
Я вспоминаю своих преподавателей, с которыми в студенчестве работал на кафедре - профессионалы, очень умные люди. Но если бы кто-то из них рискнул со своим подходом к разработке программного обеспечения вылезти за пределы кафедры - сожрали бы в момент! Подход не тот. И сейчас я вижу примерно такие же рассуждения здесь. Админы, что ли о разработке софта рассуждать взялись? Не надо. У админа есть своя область приложения его умений, просторная, как приполярная тундра.
И если теоретик появится посреди такого проекта и начнет говорить, что язык, на котором проект пишется использует плохую модель наследования, то пусть не удивляется, когда схлопочет по репе, потому, что у разработчиков хватает дел и без теоретиков от программирования.


Полуденный Бес

anonymous
()

ПРЕАМБУЛА:
Говорю о ПРИКЛАДНОМ программировании, одной из отличительных черт которого - некритичность задачи в отношении времени реакции системы.

ПРИМЕЧАНИЕ:
Java предназначена именно для ПРИКЛАДНОГО программирования и то, кто желает увидеть приличную СУБД на Java пусть встанет под холодный душ, глядишь постигнет дао или еще какую байду, или помрет от воспаления легких, да и хер с ним, таких мыслителей не жалко. А гражданин, пожелавший увидеть Doom на Java пусть меняет род занятий - компьютеры ему запрещены по медицинским противопоказаниям(за подробностями - к психиатору).

ФАБУЛА:
Блядь! Блядь! Сколько же надо по бестолковке бить, что бы стала понятна простейшая мысль: БЕЗРАЗЛИЧНО НА ЧЕМ РЕАЛИЗОВЫВАТЬ ЗАДАЧУ, если ты укладываешься в сроки, деньги и ТЗ. ПОХЕРУ! Java, C/C++/C#, Progress, Informix или любой другой 4GL, VB, хаскел или хераскел. БЕЗРАЗЛИЧНО! Рассуждения о "правильной" или "неправильной" струкуре языка - это прерогатива кафедральных теоретиков, НИКОГДА НЕ РАБОТАВШИХ НА РАНОК СОФТА. "Наследования, функторы - пиши сука!". Приладной софт - это много правильно работающего кода. 5-10-20 мегабайт исходного текста. Когда распечатанный на ленточном принтере текст проекта достает чуть не до плеча. Все. Правильно работающий код можно написать на любом языке, это, надеюсь, сомнений не вызвает?
Я вспоминаю своих преподавателей, с которыми в студенчестве работал на кафедре - профессионалы, очень умные люди. Но если бы кто-то из них рискнул со своим подходом к разработке программного обеспечения вылезти за пределы кафедры - сожрали бы в момент! Подход не тот. И сейчас я вижу примерно такие же рассуждения здесь. Админы, что ли о разработке софта рассуждать взялись? Не надо. У админа есть своя область приложения его умений, просторная, как приполярная тундра.
И если теоретик появится посреди такого проекта и начнет говорить, что язык, на котором проект пишется использует плохую модель наследования, то пусть не удивляется, когда схлопочет по репе, потому, что у разработчиков хватает дел и без теоретиков от программирования.


Полуденный Бес

anonymous
()

To Antichrist:
Re: o servernoi arhitekture analogichno Servlet'am dlya C
Sdelali. Ya sam sdelal pravda dlya C++. i bolee razvitaya chem servlety.
dalshe to chto ?
K voprosu o sistemnom PO na JAVA
JavaOS uzhe est, BD na JAVA est (celikom) necelikom skazhem Jasmine est :) + Oracle sobiraetsya polzhti tuda. Voobshe dolzhen poyavitsya kamushek kotoriy budet molotit bait-cod pravda na nem budet rabotat tolko odna operacionka - JavaOS a pod nei tolko prilozheniya na JAVA...

master
()

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

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

dvb
()

ПРЕАМБУЛА:
Говорю о ПРИКЛАДНОМ программировании, одной из отличительных черт которого - некритичность задачи в отношении времени реакции системы.

ПРИМЕЧАНИЕ:
Java предназначена именно для ПРИКЛАДНОГО программирования и то, кто желает увидеть приличную СУБД на Java пусть встанет под холодный душ, глядишь постигнет дао или еще какую байду, или помрет от воспаления легких, да и хер с ним, таких мыслителей не жалко. А гражданин, пожелавший увидеть Doom на Java пусть меняет род занятий - компьютеры ему запрещены по медицинским противопоказаниям(за подробностями - к психиатору).

ФАБУЛА:
Блядь! Блядь! Сколько же надо по бестолковке бить, что бы стала понятна простейшая мысль: БЕЗРАЗЛИЧНО НА ЧЕМ РЕАЛИЗОВЫВАТЬ ЗАДАЧУ, если ты укладываешься в сроки, деньги и ТЗ. ПОХЕРУ! Java, C/C++/C#, Progress, Informix или любой другой 4GL, VB, хаскел или хераскел. БЕЗРАЗЛИЧНО! Рассуждения о "правильной" или "неправильной" струкуре языка - это прерогатива кафедральных теоретиков, НИКОГДА НЕ РАБОТАВШИХ НА РАНОК СОФТА. "Наследования, функторы - пиши сука!". Приладной софт - это много правильно работающего кода. 5-10-20 мегабайт исходного текста. Когда распечатанный на ленточном принтере текст проекта достает чуть не до плеча. Все. Правильно работающий код можно написать на любом языке, это, надеюсь, сомнений не вызвает?
Я вспоминаю своих преподавателей, с которыми в студенчестве работал на кафедре - профессионалы, очень умные люди. Но если бы кто-то из них рискнул со своим подходом к разработке программного обеспечения вылезти за пределы кафедры - сожрали бы в момент! Подход не тот. И сейчас я вижу примерно такие же рассуждения здесь. Админы, что ли о разработке софта рассуждать взялись? Не надо. У админа есть своя область приложения его умений, просторная, как приполярная тундра.
И если теоретик появится посреди такого проекта и начнет говорить, что язык, на котором проект пишется использует плохую модель наследования, то пусть не удивляется, когда схлопочет по репе, потому, что у разработчиков хватает дел и без теоретиков от программирования.


Полуденный Бес

anonymous
()
Ответ на: комментарий от anonymous

СтранниК для Полуденный Бес

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

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

По большому счету есть такая наука экономика. И вот наверно основываясь на ней и надо решать на чем писать. СтранниК

anonymous
()

Прошу прощения за повторы, машинку переплющило.

Полуденный Бес

anonymous
()

2 Станник
"По большому счету есть такая наука экономика. И вот наверно основываясь на ней и надо решать на чем писать." - иес, согласен! Кроме нее есть еще несколько факторов, они варьируются от проекта к проекту и бог с ними. Но никогда такие слова как "полиморфизм" и тому подобные не должны определять на чем будет реализован проект.
А что да правильности решения - то это к Бруксу, у него там хорошо написано.

Полуденный Бес

anonymous
()
Ответ на: комментарий от BlackRabit

> Пример внутреннего противоречия:
> Большие не-интернет проекты ( 1e5 строк кода ) должны стать
> переносимы хотя бы между основными интелевскими осями ( win32, linux,
> free, os2, be ). Не по искходникам, а по jar, разумеется.

Вам показать в действии Together, JBuilder или NetBeans? Поверьте, в них
больше чем 1e5 строк кода.

> Хотя бы doom 1 на Jave, хотя бы на PII-233 RAM 128 -- слабо?

ЗАЧЕМ?

> На Jave легче писать -- сборка мусора головная боль, но попробуй
> гарантированно удали ссылку на уникальный объект -- сборщик
> когда захочет тогда и удалит.
Во-первых, под влияние GC объект попадет только после того, как потеряны
все значащие жесткие ссылки на него (т.е. не образующие циклов, etc.,
давайте не будем сейчас вдаваться в подробности алгоритма. Предположим, что в простейшем случае не должно остаться ни одной
жесткой ссылки). Ну так вот, если у вас нет ни одной жесткой ссылки на объект => он вам больше НЕ НУЖЕН. Тогда почему вас волнует то, когда
его соберет GC, если, конечно, вы не пишете RT-систему?
Во-вторых, даже объектами, на которые потеряны все жесткие ссылки,
вы можете в некоторой степени управлять при помощи WeakReference и
SoftReference.

> Пару месяцев назад у друга из соседней фирмы неудался java-проект
> -- тяжело было бороться с низкой производительностью на hi-end
> сервере.
Из этого следует, что Жаба -- плохой язык с множеством внутренних и
внешних противоречий? Простите, не верю. Из этого следует ровно то,
что уважаемый приятель не сумел на Жабе выполнить поставленную задачу,
а причины этого могут быть самыми разными -- от кривости Жабы до ...
мнэээ... не очень хорошего знания Жабы разработчиком.

BarD
()

2 BarD: Какой такой GC для RT системы? ;) Только статическое распределение :)

-- wart

anonymous
()
Ответ на: комментарий от dvb

Золотые слова! Только бы ещё все додумались понять, что к Java они относятся в той же степени, что и к Perl, и, соответственно, весь разведённый жабаненавистниками вроде меня флейм - всего лишь пустой трёп. Но всё равно - глюкавый GC - это позор. Лет 20 уж вся теория разложена по полочкам, в том числе и для риалтайма, а всё равно находятся умельцы, способные всё запоганить. Абыдна.

Antichrist
()
Ответ на: комментарий от BlackRabit

> Хотя бы doom 1 на Jave, хотя бы на PII-233 RAM 128 -- слабо? 

 Ты тогда так же далеко пошли C Shell, Perl, Tcl, Lua, CINT,
Python, и все остальные заслуженные и необходимые в хозяйстве языки,
на которых 3д-шутера не напишешь.

> Большие не-интернет проекты ( 1e5 строк кода ) должны стать 
> переносимы хотя бы между основными интелевскими осями ( win32, linux, 
> free, os2, be ). Не по искходникам, а по jar, разумеется. 

 А я то думал, что все мы тут уже сошлись на том мнении, что
Жаба - для server side applications only, ну и немного для distributed
applications, и, конечно же, как исследовательская платформа
для distributed agent applications. При чём тут графика и прочая
непортабельная параша?

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

 А ЗАЧЕМ?!?

> Пару месяцев назад у друга из соседней фирмы неудался java-проект 
> -- тяжело было бороться с низкой производительностью на hi-end 
> сервере. 

 Performance tips курить надо было.

Antichrist
()
Ответ на: комментарий от master

> Re: o servernoi arhitekture analogichno Servlet'am dlya C 
> Sdelali. Ya sam sdelal pravda dlya C++. i bolee razvitaya chem servlety. 
> dalshe to chto ? 

 Позвольте не поверить. Возможно, пул тредов, динамическую загрузку
сервлетов и выгрузку их же, пришибание ненужных объектов по таймауту
сделать на C++ и можно (только траходром это тот ещё будет),
но вот секьюрити там не будет никакого - нельзя сервлеты друг от
друга оградить, не позволить чужие файлы читать, и т.п. - а это,
IMHO, одна из наиважнейших фичей сервлетов.

> Oracle sobiraetsya polzhti tuda

 Да уже заполз так, что смотреть тошно. Если так будет продолжаться,
забью я на Оракл :(

> Voobshe dolzhen poyavitsya kamushek kotoriy budet molotit
> bait-cod pravda na nem budet rabotat tolko odna operacionka -
> JavaOS a pod nei tolko prilozheniya na JAVA... 

 Такие камушки уже есть, и не один, Java в OS не нуждается,
и под JVM работает туева хуча других языков, окромя Жабы - в
том числе и весьма правильных. К примеру, есть MLj - компилятор
Standard ML в JVM, весьма неплохой. Есть Kawa - компилятор Схемы,
которую я весьма активно юзаю и никаких претензий не имею, окромя
принципиального для JVM отсутствия корректной отработки хвостовой
рекурсии. Есть и другие языки, даже Prolog.

Antichrist
()
Ответ на: комментарий от dvb

Нет уж. Оптимизация низкоуровневых операций - это самое незначительное, что может делать компилятор (e.g. немерянно производительный и шустрый компилятор языка Objective Caml эту стадию практически полностью игнорирует). Гораздо важнее оптимизация более высокого уровня - и тут как раз заточенные под задачу языки имеют массу преимуществ по сравнению с более общими языками - в них наличествуют высокоуровневые конструкции, про которые компилятор завсегда знает, что с ними делать. К примеру - в Фортране есть массивы, матрицы, вырезки, есть операции над ними - и компилятор завсегда их может разпараллелить на фиг. В C++ вообще нет никаких массивов, и уж тем более нет высокоуровневых операций над такими объектами - так что компилятор должен быть долбанным гением от искусственного интеллекта, чтобы распознать работу с матрицей в прожеванном им коде. Такие вот пироги, товарищи. Читайте про теорию компиляции, и не выдавайте свои интуитивные, нестрогие представления за что-то заслуживающее внимания.

Antichrist
()
Ответ на: комментарий от anonymous

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

Antichrist
()
Ответ на: комментарий от Antichrist

> Performance tips курить надо было.
Или еще какую-нибудь полезную травку :)



BarD
()

>>Если так будет продолжаться, забью я на Оракл :(
Дык забей. Кто против. Тока альтернативу предложи сначала.

И вообще, антихрист ты или ка тебе нравиться себя обзывать, перестань постить сообшения по 5 штук подряд. Собирись мыслями, напиши одно, пусть даже большое. А то такое подозрение что у тебя недережание не только мыслей :))


ifconfig
()
Ответ на: комментарий от justme

>выбрал С, потому что он был лучше? Не верится мне.
а ты все-таки постарайся поверить, зачем же так предвзято. И не 3-4, для выбора этого слишком мало.

>если к этому делу надо будет ГУИ, обязательно его писать именно на Си?
ГуЙ я на С писать не буду, максимум - что-то предельно мелкое. Да и не ГУем я занимаюсь...(не сошелся на нем свет клином, поверьте)

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

random
()
Ответ на: комментарий от Antichrist

2антихруст
>этот же человек начнёт кричать, что "Java - дерьмо,
>VB - дерьмо, их блин разрекламировали, и всё такое".
Слушай, перевозбужденный холерик, остынь немного, изъясняйся без брызжущей изо рта пены, надоело монитор протирать. Давай ты не будешь заниматься прогнозированием в свободное от онанизма время. И не надо ставить мне в вину слова собственного сочинения. Или ты предпочитаешь разговаривать сам с собой? В таком случае делай это дома перед зеркалом и не надо на весь форум позориться. Я буду отвечать только за _м_н_о_ю_ сказанные слова.

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

>ты, гуманитарчик?
Это тебе бабушка на полете страуса нагадала? С тем же успехом могу высказать предположение, что ты - ассенизатор (если ты, конечно, знаешь, что это такое)

>С какой радости тебя интересует скорость
>выполнения кода, в коем процессор проводит <10% от общего затраченного
>времени?
Граждане! Интересную мысль высказал тов. Антикарст. Он предполагает, что в задаче, производящей огромные вычисления с помещающимися в регистры данными, практически не читающей данные ни с периферии, ни с носителей, доля процессорного времени не более 10%. Какая оригинальная идея! Пожалуй помещу в раздел "юмор".
Ты, прикладник несчастный, ты вообще представляешь задачи, отличные от дифуров, ЧМа и вычисления кривизны траектории летящего куска грязи? Видимо нет, почитай что-нибудь,а?

>90% кода без потери общей производительности можно будет
>переписать на самый тормозной интерпретируемый язык.
Напиши на васике компилятор, а еще лучше - драйвер, вот поугораю!

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

З.Ы. Знаешь за кого у нас держат прикладников? За недоумков, неспособных заниматься настоящим делом, т.е. за гандонов.

random
()
Ответ на: комментарий от Antichrist

2антихруст
>ы никогда не замечал, что НИ ОДИН крупный проект на языке без GC
>не обходился без подобных тулзей?
назови мне хоть один крупный проект не на С, который был бы без глюков

>Ну так доказывай. Исходя из строгой математической теории.
>А твои гуманитарские вопли про "100000 леммингов не могут ошибаться"
Я не знаю что ТЫ понимаещь под "строгой матетатической теорией". Но мне известно, что математическая логика и программистская логика - совершенно разные вещи. Много есть математиков и физиков, упорно доказывающих, что они классные кодеры, да так до сих пор и вопят в форумах. Математику/физику - разработка алгоритма, и держать его подальше от компа, чтобы неправильным образом мыслей нормальных программеров не заразил. Это - не совместимо. А насчет леммингов, так вообще только ты вопишь.

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

>) Наличие ПРИНЦИПИАЛЬНО непредсказуемых сайд-эффектов, следующих
>из особенностей арифметики указателей
а ты уверен, что правильно используешь указатели? Исходя из выше сказанного у меня боольшие сомнения.

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

>ненадёжным низкоуровневым дерьмом
ты видел, какие вещи на асме пишутся? Небост не знаешь, сколько тактов занимает переброска из счесчика в аккумулятор, а все туда же - оценивать языки назкого уровня. Ты выучи сначала 3-4 разных ассемблера, а потом рассуждай.

P.S. Кстати, антихряк, здорово насчет тебя в форуме Talks проехались!

random
()
Ответ на: комментарий от Antichrist


Ты вообще когда-нибудь смотрел *.h файлы так нелюбимого тобой C из каталога sys или ты обломался при запуске проги собранной на i86 и запущенной на SPARC (скорее всего это был hello world набранный тобой из учебника по С образца 1970 года за авторством неизвестного гения атомной физике)
Поясняю подавляющее большинство подобных проблем решается перекомпиляцей на целевой платформе (кроссплатформ не всегда катит), но естественно для этого НАДО писать под OpenSource (т.е. иметь храбрость распискаться за свои дела и в случае чего свою тупость).
Так же твой хваленый фортран использует С-библиетеки (если ты понял смысл фразы), так как они более быстродейственны, и распаралеливание происходит на уровне библиотек и препроцессора (Read the Fucking Source)
И потом ты что нормально свою мысль изьяснитьне можешь IMO если челевек начинает орать и крыть всех матом то либо он просто неполноценный, либо социально травмированный, а скорее всего просто ничего не знает так как понахватался верхов
P. S. не всякий красивый математический алгоритм красиво и главаное удобно и быстро реализовывается в программирование. Так что еще раз почитай теорию а лучше посмотри source (хотя по-моему тебе не поможет)

anonymous
()
Ответ на: комментарий от anonymous

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

Antichrist
()
Ответ на: комментарий от ifconfig

> Тока альтернативу предложи сначала.

А я к бимерам пойду, на DB2. Как будто мало сейчас RDBMS уровня Оракла наплодилось...

> перестань постить сообшения по 5 штук подряд

Надо же всем ответить. А большие TEXTAREA в этом сволочном Нетшкафе, на C++ писаном, к таким ликам приводят, что гига RAM и 4Gb свопа не хватает.

Antichrist
()
Ответ на: комментарий от random

> назови мне хоть один крупный проект не на С, который был
> бы без глюков 

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

> Я не знаю что ТЫ понимаещь под "строгой матетатической теорией". 

 Естественно. Куда уж тебе, безмозглому мудаку, в теориях разбираться.
Итак, основываюсь я на:
1) типизированная теория множеств
2) Лямбда-исчисление в терминах теории множеств
3) Статическая типизация поверх 2)
4) Формализм Тьюринга для описания императивщины
5) Теория dataflow для приведения императивщины к лямбда-виду.

> А насчет леммингов, так вообще только ты вопишь. 

 Нет уж, пиздобольчик, это ТЫ вопишь, что "на Цэ писано до хрена,
значит Цэ рулит". Это и есть знаменитый гуманитарский аргумент
имени леммингов.

> Кстати, это и есть одна из его сильных сторон, и
> если ты не знаешь, как приводить типы, то не
> жалуйся на язык,

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


> а ты уверен, что правильно используешь указатели?

 Правильно их использовать - это не использовать их совсем.

> Исходя из выше сказанного у меня боольшие сомнения. 

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


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

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

> Ты выучи сначала 3-4 разных ассемблера, а потом рассуждай. 

 Я писал на ассемблере PDP11 и MACRO11 (VAX), когда ты и Z80 в глаза
не видел. Так что сдохни, хуесос.

Antichrist
()
Ответ на: комментарий от anonymous

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

Короче, ламо, или ты сейчас споёшь песенку про то, как сражаешься
с проблемами с unaligned access, какие врапперы пишешь, дабы
забороть разницу промеж RTL даже только якобы Posix-совместимых
систем, ну, к примеру, в пределах i386-gnu-linux, alpha-dec-osf1, 
sparc32-sun-sunos26, sparc64-sun-solaris, и до кучи вся ветка
ARM-ов, или униженно просишь прощения и публично заявляешь, что
ты - полный ламер, который не имеет права на существование и
должен быть уничтожен в порядке очистки генофонда Человечества.

 Учти, я для Цэ для всех перечисленных платформ + Win32 и MacOS
эту проблему решил. Но это весьма дорого стоило. В то же время
Схема и Фортран на всех платформах никаких лишних телодвижений
не требуют - достаточно перекомпиляции.

> Так же твой хваленый фортран использует С-библиетеки 

 Умри, ламер. Ты просто Фортрана не видел. Посмотри хотя бы
на DEC Fortran90 под Digital Unix.

> и распаралеливание происходит на уровне библиотек и препроцессора

 Давно мне не попадались такие наглые и самоуверенные безмозглые
ублюдки. Ты явно не представляешь себе, что такое АВТОМАТИЧЕСКОЕ
разпараллеливание на SMP. Поверх PVM3 ручками параллелить - далеко
не всегда и не везде можно.

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

Antichrist
()

Для Анчихриста,

Остановись, пока не поздно, покайся Богу,
Он простит, Он великодушен.
Спаси душу свою пока не поздно, иначе
будешь гореть ты в Аду в огне вечном, ибо Господь наш все видит и
и не прощает глумления над Верой Христианской, Православной.
Лиди на смерть за Крест шли, Солдат в чечне креста не снял,
смерть лютую принял.
А ты богохульствуешь.
Опомнись, поздно будет.

anonymous
()
Ответ на: комментарий от Irsi

2Irsi

Специально обращаю ваше внимание:
существуют несколько классов систем реального времени, в зависимости от типа событий которые они обрабатывают и способа обработки.
События могут быть синхронные и асинхронные. Синхронные события - это события происходящие в известные моменты времени (например управление в движок выдается с заданной частотой дискретизации).
Асинхронные события это события момент возникновения которых непредсказуем - они характеризуются мат. ожиданием частоты возникновения и предельной частотой возникновения,
Если система должна обрабатывать асинхронные события - это система минимального времени, так, как теоретически может возникнуть несколько событий _одновременно_ и просто гарантий на вермя реакции системы (например на время возврата из обработчика прерывания) здесь не достаточно.
Если обрабатываются синхронные события - ситуация весьма проще, в каждый момент времени возникает только строго известное количество событий (чаще всего одно).
Последний класс - это интерактивные системы (системы мягкого реального времени) к числу которых относится и Линукс. Вермя реакции в них прямо пропорционально производительности системы, но для многих задач остается в приемлемых приделах.
Ваше определение real-time system неверно. Оно не отражает указанного выше деления на классы по типу событий. Правльное гласит - real-time system это вычислительная система время обработки события в которой зависит только от типа события и не зависит от других факторов (порядка поступления событий вриантов изх комбинаций и тёп)
Такая система для каждого события, имеющего место быть в системе определяет мат. ожидание его времени обработки (т.е. когда _закончится_его_обработка, а не начнется обработка следующего) и дисперсия этого времени.
Я имел в виду, что решения основанные на жабе и тп в принципе представляют собой третий класс систем (мягкое реальное время) и получить из них систему минимального времени невозможно.

rivares
()
Ответ на: комментарий от Antichrist


Ну раз ты так ругаешься, значит на счет квалификации я в точку попал! Бедненький, на работе не ужажают, платят мало, да еще в LOR обидели. Сочувствую ...
А что до проектов - их хватает. Например с ПрО ракет можно ошибки пересчитать по пальцам (ну например случай с Ариан 5). правда там не то чтобы очень очевидная ошибка была.
Ну да ладно, маленький, ты не обижайся, покричи. поругайся - душе легче станет.

rivares
()

Что самое интересное не может привести альтернативу С/С++.
Интересно было бы почитать доказательство правильности кода в исполнении Антихриста.

Havoc ★★★★
()

Заглянул к ВАМ тут... Клёво.... Выскажусь: 1) Java не есть хороший ЯЗЫК. Моя личная точка зрения. Сам проверял (3.5 года). Только сейчас понял какой хернёй занимался.

2) C будет жить ещё долго (по крайней мере дольше чем Java) А про кучу проектов и кода которую успели нагородить на Java - нагородят ещё на чём либо(С# например или чё нить другое)

P.S. Смотрел недавно С# ..... ;-)

anonymous
()

2 Antihrist: а как ты относишься к языкам модула и оберон, и т.д.?Интересно было бы почитать твои обзоры ( естественно с хорошими матюками:))) по поводу разных языков.Что-то типа странички http://www.people.virginia.edu/~sdm7g/LangCrit/index.html ?Может сообразишь что-нить этакое?:))

anonymous
()

2rivares: вот теперь понятно что Вы имели ввиду, в такой форме - пожалуй согласен ;)
BTW, согласен - Ваше определение RT систем более полное... Просто боюсь что большинство линуксоидов не знают что такое мат. ожидание и т.д. ;) Ну соответственно здешнему среднему уровню я и высказался, чтоб хоть что-то поняли ;)

Irsi
()

speer а твой проджект Д че-то слишком на яву похож...Чем он лучше-то?

anonymous
()

Слушай vsl а ты не пробовал об этом в сан написать(поп поводу их JVM)?Может они что изменят к лучшему...:)

anonymous
()
Ответ на: комментарий от Antichrist

2антихряк
Тебе не надоело еще онанизмом страдать, ты, недоматематик несчастный? Видать не смог освоить курс арифметики в обьеме младшей школы (и русского языка), так в кодеры полез.
Мне (да и многим до меня) уже надоело указывать тебе на ошибки. Но, видимо, горбатого могила исправит.
Перестань разговаривать сам с собой! Надоело слушать, как ты сам у себя спрашиваешь и сам же себе отвечаешь (к тому же часто неверно).

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

random
()

2Irsi: мат. ожидание? Нет ничего проще! Это ожидание мата, вот, например, у антикреста очень высокий показатель этой величины.

PS: Ответ твой всё равно выглядит как если бы ты прочитал что-то новое, но в грязь лицом ударять стыдно, а заодно "линуксоидов" пнуть. Некрасиво, неужто "Ogr" повлиял?

Casus ★★★★★
()

2random
На счет Talks - заблудился парень, не туда запостил.
Опускали его в другом месте :)

anonymous
()

Вообще весь этот "вя про жабу" исходит от тех, 
кто 
1)так и не СУМЕЛ НАУЧИТЬСЯ хоть малость 
писать на C. 
2) никакого другого программирования, 
 кроме  как для Web, не видел


Для таких героев следдующий C просто непосилен.


Bear

anonymous
()

>> Ну-к, кто сможет сделать на жабе решение нелинейных дифуров?
>> Хрен вы это сделаете!

> Кто станет это на C/C++ делать - не меньший ламо. Для этого
> дела Фортран есть.

Может я и ламо, но С удобнее ( если умеешь)
Последний статдарт С перекрывает Фортран даже для 
сугубо "прикладных" задач

Bear

anonymous
()

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

Havoc ★★★★
()
Ответ на: комментарий от anonymous

уже не люблю C#! Спи$дили из Java ВСЕ...кроме самого лучшего(интерфейсы IMHO) http://www.ozon.ru./detail.cfm/ent=2&id=51895 обрати внимание на раздел "Лучшие в этом жанре"..... смеялся я долго :)))))

anonymous
()
Ответ на: комментарий от Irsi

2Irsi - 2

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

rivares
()
Ответ на: комментарий от anonymous

> Спи$дили из Java ВСЕ...кроме самого лучшего(интерфейсы IMHO) В C# есть интерфейсы. Даже более того, есть возможность в классе указывать, к какому интерфейсу относится данный метод. Эта фича бывает очень полезна.

BarD
()

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.