Востребованность языков программирования

Перенос из темы «Что, господа суровые С++ программисты, поспорим быстродействием с отстойной Джавой? ;)»
 
1 2 3 4 5 6 7
BG Реконструктор #03.09.2011 15:30  @Balancer#02.09.2011 19:58
+
-
edit
 
Balancer> Это и есть web-программирование. Впрочем, мы уже убедились, что тема эта тебе совершенно не знакома.

Да, я уже понял - веб программирование это прокладка между функциональностью сайта и браузером. :) Разные индексаторы, веб-краулеры, перекодировщики, словари и прочий мусор в это понятие не входят. И да, там пхп с джавами рулят стопудово. :D И да, я объявляю очередную победу PHP/Java и Цифрового Сергея/Балансёра. :D

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

Я понимаю, что для стандарного CNN зрителя это может прозвучать абсурдно, но в природе существуют личности, которым глубоко наплевать как они ввыглядят. :) Я всегда считал нигилизм - своего рода русской национальной философией, но теперь видно, что эта большая ценность постепенно умирает. Но это, разумеется, глубокий оффтопик.
 6.06.0
IL digger #13.09.2011 16:42  @Реконструктор#03.09.2011 15:30
+
-
edit
 

digger

аксакал

А большинство сайтов и не содержат нетривиальных компонент, требующих собственно программирования.Задача - соединить вместе уже существующие компоненты, базу данных с ГУЕм типично.Если же наоборот, сайт - игра например, то игрописание там будет 99% проекта,к Вебу прямого отношения не имеющего.
Что касается не производительности,а собственно программирования - не перевариваю я недоязыки, неудобно на них писать действительно сложные вещи.
 3.6.83.6.8
US Сергей-4030 #13.09.2011 17:22  @digger#13.09.2011 16:42
+
+1
-
edit
 

Сергей-4030

исключающий третье
★★
[size=50]digger> Что касается не производительности,а собственно программирования - не перевариваю я недоязыки, неудобно на них писать действительно сложные вещи.

И много уже написали действительно сложных вещей? Не поделитесь?

PS До смешного доходит. Java, которая со всех "языковых" характеристик безусловно превосходит плюсы, объявляется "недоязыком". Ладно бы критиковать производительность. Там все не так плохо, (как теперь уже знает по опыту господин Реконструктор :lol:), но кое-какие слабые места остаются. Правда чтобы знать, что это за места, надо быть более-менее в курсе технологии. А что-то мне подсказывает, что digger, как и все предыдущие критики, про Java знает в основном из комиксов.
 13.0.782.22013.0.782.220
IL digger #13.09.2011 17:41  @Сергей-4030#13.09.2011 17:22
+
-1
-
edit
 

digger

аксакал

Сильно крупный проект, который никогда не прекращается по своей природе, что - не скажу :).В Жабе например раздражает указание классов в каждом операторе и гипертофированно-классовая структура, там где они нафиг не нужны.Также отсутствие пойнтеров и платформно-зависимых типов, неудобно на ней парсить файл, например.Недоязык - потому что нет рукопашной связи между кодом и результатом, скрипт это.На С вот переменная,вот ее место в стеке, код непосредственно связан с машинным кодом.Переносимость обеспечивается наличием компилятора и правильным написанием.
 3.6.83.6.8
US Сергей-4030 #13.09.2011 17:55  @digger#13.09.2011 17:41
+
+1
-
edit
 

Сергей-4030

исключающий третье
★★
digger> Сильно крупный проект, который никогда не прекращается по своей природе, что - не скажу :).

Да уж понятно. А как насчет проектов на Java? Вы заметили, весь "наш" лагерь - Мишка, Рома, я и остальные - работали над большими проектами как в плюсах, так и на Java. А вы работали с большими проектами в Java? Сколько раз повторять-то можно, мы про C++ знаем если не все, то очень многое (последние веяния, может, не знаем, потому что отошли). А вы про Java знаете только то, что Реконструктор пишет в своих фантазиях.

digger>В Жабе например раздражает указание классов в каждом операторе и гипертофированно-классовая структура, там где они нафиг не нужны.

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

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

Недавно мы вот с Реконструктором файлы парсили, и у меня (на Java) лучше получилось. Не странно ли?

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

А вы знаете, что такое JIT компиляция? Что за глупости "нет рукопашной связи"? Во-первых, класс задач, где действительно нужна "связь с машинным кодом" очень узок, ограничивается, по сути, драйверами устройств. И практика показывает, что именно туда плюсы и вытесняются мало-помалу. Во-вторых, про переносимость даже не начинайте. Сравнивать переносимость плюсов и Java могут только совсем уж безбашенные юмористы типа Задорнова и Реконструктора. Вы просто не въезжаете. Вы такого не видели никогда в своем плюсном мире - берем хороший такой проект, с развитым UI, с хорошей серверной частью, работающий на PC, копируем файлы на Мак (не перекомпилируем даже) - и вуаля, все тут же работает. На плюсах до такого плыть и плыть.
 13.0.782.22013.0.782.220
IL digger #13.09.2011 18:15  @Сергей-4030#13.09.2011 17:55
+
-1
-
edit
 

digger

аксакал

>А вы работали с большими проектами в Java?

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

>Сергей-4030> В смысде - вы к ним не привыкли, это вы имеете в виду? Хэдеры сишных модулей куда более массивны и вообще, прямо говоря, решение довольно неизящное.

printf vs sys.print.out

Сергей-4030> Недавно мы вот с Реконструктором файлы парсили, и у меня (на Java) лучше получилось. Не странно ли?

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

Сергей-4030> А вы знаете, что такое JIT компиляция? Что за глупости "нет рукопашной связи"?

Предрассудки с моей стороны.JIT - это всего лишь внутренняя фича интерпретатора.

>копируем файлы на Мак (не перекомпилируем даже) - и вуаля, все тут же работает.

Вы копируете его на установленную там жабную виртуальную машину, так нечестно :). Понятно,что такая переносимость лучше.
 3.6.83.6.8
+
+2
-
edit
 

Mishka

модератор
★★★
digger> printf vs sys.print.out

М-да. А когда можно использовать printf? А не знаком, что надо в Джаве, чтобы не писать sys? А что такое namespace в C++ не знаком? И как в C++ с namespace работают?

digger> В С кусок файла засасывается в буфер и оттуда непосредственно читаются данные.

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

digger> Вы копируете его на установленную там жабную виртуальную машину, так нечестно :). Понятно,что такая переносимость лучше.

Блин, вот тебе пара примеров. Как ты работаешь на C/C++ с big/little endian? А ты знаешь, что по стандарту С/C++ порядок битов в битовой структуре не определён?
code c++
  1. struct
  2. {
  3.     unsigned short icon : 8;
  4.     unsigned short color : 4;
  5.     unsigned short underline : 1;
  6.     unsigned short blink : 1;
  7. } screen[25][80];

Ты не знаешь в общем случае, будут биты справа налево или наоборот считаться. Скажем, Sun компилятор считает их в обратном направлении (по отношении к большинству других компиляторов). У нас из-за этого были вырванные годы, когда попытались писать в БД на Сане, а читали на Linux, HP-UX, Windows. Народе дефайнерами обходился, но периодически попадались, т.к. это надо было всегда и всем знать. Пришлось мне написать класс singleton с поддержкой ниток для автоматического определения и создания через factory LE/BE и порядка битов в 32 битном слове. Это к переносимости.
 6.06.0
US Сергей-4030 #13.09.2011 19:08  @digger#13.09.2011 18:15
+
+1
-
edit
 

Сергей-4030

исключающий третье
★★
digger> printf vs sys.print.out

Никто вам не запрещает написать что-то свое. У меня скажем есть App.info("tralala"). Что, на минуточку, лучше, чем писать в стандартный вывод.

Сергей-4030>> Недавно мы вот с Реконструктором файлы парсили, и у меня (на Java) лучше получилось. Не странно ли?
digger> В С кусок файла засасывается в буфер и оттуда непосредственно читаются данные.

Во-во. Офигенный пример того, как легко и просто в плюсах можно получить огромные дурацкие проблемы. Впрочем, Миша уже сказал.
 13.0.782.22013.0.782.220
US Сергей-4030 #13.09.2011 19:21  @digger#13.09.2011 18:15
+
-
edit
 

Сергей-4030

исключающий третье
★★
digger> Вы копируете его на установленную там жабную виртуальную машину, так нечестно :). Понятно,что такая переносимость лучше.

Я не понял, что значит нечестно? За те 20 минут, пока я качаю и устанавливаю JVM для Мака, вы успеете поменять UI с виндосных виджетов на маковские, найти/поправить все несовместимости, перекомпилировать исходники и переписать деплойер/установщик?
 13.0.782.22013.0.782.220
RU Серокой #13.09.2011 19:27  @Mishka#13.09.2011 18:46
+
-
edit
 

Серокой

координатор
★★★★
Mishka> писать в БД на Сане, а читали на Linux, HP-UX, Windows.

А может это от архитектуры ядра зависит? Другими словами, этот компилятор под Солярис работает на Спарках так, а на интеле - этак.
Кстати, индианити эта - такая головная боль...
Больше не раскалятся ваши колосники. Мамонты пятилеток сбили свои клыки. ©  
IL digger #13.09.2011 19:34  @Серокой#13.09.2011 19:27
+
-
edit
 

digger

аксакал

Естественно, архитектура процессора.Но биты считаются всегда от менее значимого к более, >> 2 - всегда *2.Там еще прелести с выравниванием, прочитал байт по нечетному адресу - и писец.

>И все используют внутренние буфера. А, если ты имеешь свой буфер, то будет двойная буферизация.

Дело не в скорости,а в непосредственном чтении из памяти,а не по одной переменной из файла.Как вы будете МZ header или другую структуру например загружать в Жабу?
 3.6.83.6.8
US Mishka #13.09.2011 19:44  @Серокой#13.09.2011 19:27
+
-
edit
 

Mishka

модератор
★★★
Серокой> А может это от архитектуры ядра зависит? Другими словами, этот компилятор под Солярис работает на Спарках так, а на интеле - этак.
Серокой> Кстати, индианити эта - такая головная боль...

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

Код
code c++
  1. struct Bits
  2. {
  3.     unsigned short firstBit : 1;
  4. };
  5. Bits bb;
  6. bb.firstBit = 1;


В одном случае развернётся в:
code c++
  1. bb |= 0x00000001;

а в другом в:
code c++
  1. bb |= 0x80000000;
 6.06.0

Mishka

модератор
★★★
digger> Естественно, архитектура процессора.Но биты считаются всегда от менее значимого к более, >> 2 - всегда *2.Там еще прелести с выравниванием, прочитал байт по нечетному адресу - и писец.

Нет. Это сдвиг битов вправо на 2 — деление на 4. Операция однозначно задаёт направление, а второй операнд — на сколько. Никакого отношения к подсчёту битов.

Выравниваение тоже не имеет отношения к битовому представлению. По стандарту битовое поле всегда в слове 32 битном, поэтому, как правило, выравнено на границу 4 байт.

digger> Дело не в скорости,а в непосредственном чтении из памяти,а не по одной переменной из файла.Как вы будете МZ header или другую структуру например загружать в Жабу?

Блин, ты, когда используешь ввод, то уже читаешь из буфера. :) Из файла читается буфер. Размер буфера на том же юнихе можно менять.

Как загружать? :) Посмотри на библиотеки сжатия, к примеру.
 6.06.0

digger

аксакал

Mishka> Нет. Это сдвиг битов вправо на 2 — деление на 4. Операция однозначно задаёт
направление, а второй операнд — на сколько. Никакого отношения к подсчёту битов.

Опечатка, влево.Но оно одинаково на разном порядке байт в слове.

Mishka> Выравниваение тоже не имеет отношения к битовому представлению.

Это компилятор выравнивает.На некоторых процессорах чтение ворда или дворда по нечетному адресу (пойнтер в байтовом массиве) дает GPF.

Mishka> Блин, ты, когда используешь ввод, то уже читаешь из буфера. :) Из файла читается буфер. Размер буфера на том же юнихе можно менять.

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

Mishka> Как загружать? :) Посмотри на библиотеки сжатия, к примеру.

С-шные библитотеки используют тот самый буфер ,аллокацию,а следующий байт читается из него макро,которое подгружает из файла при надобности.Посмотрите gzip например.
 3.6.83.6.8
US Сергей-4030 #13.09.2011 20:36  @digger#13.09.2011 19:34
+
-
edit
 

Сергей-4030

исключающий третье
★★
digger> Дело не в скорости,а в непосредственном чтении из памяти,а не по одной переменной из файла.

Что есть "непосредственное чтение из памяти"?

digger>Как вы будете МZ header или другую структуру например загружать в Жабу?

Вот так:

public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException {
String mz = readAndCheck(in, "MZ");
lastBlock = in.readShort(in);
...
}

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

Поскольку, как Миша уже сказал, ввод-вывод буферизован, это все будет на самом деле "непосредственное чтение из памяти". При это - следите за руками - этот метод ЛУЧШЕ, чем чтение структуры, поскольку гибче и мощнее.
 13.0.782.22013.0.782.220

Mishka

модератор
★★★
digger> Опечатка, влево.Но оно одинаково на разном порядке байт в слове.

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

digger> Это компилятор выравнивает.На некоторых процессорах чтение ворда или дворда по нечетному адресу (пойнтер в байтовом массиве) дает GPF.

Нет, подсчёт битов и адрес (а адресация у нас "байтовая" и байт может быть не 8 бит) вещи ортогональные.

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

Дык, а какая разница откуда читать? :) Ну вызовешь ты прочитать 2 байта. Или твою программу и она два байта возьмёт.

digger> С-шные библитотеки используют тот самый буфер ,аллокацию,а следующий байт читается из него макро,которое подгружает из файла при надобности.Посмотрите gzip например.
Посмотри на джавовские. Посмотри на преобразование последовательности байтов в разные типы. Это же нормально.
 6.06.0
US Сергей-4030 #13.09.2011 21:37  @digger#13.09.2011 20:29
+
-
edit
 

Сергей-4030

исключающий третье
★★
digger> Я имею в виду пользовательский буфер, из которого программа читает по пойнтеру.За многократное чтение отдельных байт из файла используя функцию (невзирая на внутреннюю буферизацию), я лично расстреливал на месте.

Ага, ага. Такой подход может привести к 3 последствиям - один просто плохой, другой очень плохой и третий - полный 3.14ец. Итак, читаем прямо блоком, естественно, валидацию не делаем (ибо если делать, то никакого выигрыша вообще нет - точно так же, как в приведенном мной методе сериализации, проверяем каждое поле). И вот наступил час Ч, когда файл испортился, чтение затыкается и дает неправильные результаты, человеку, который разбирается достаточно легко найти проблему. Он страдает пять часов, находит проблему, ставит валидацию (т.е. ваше "преимущество" лаконичности потеряно). Это плохой случай. Очень плохой - QA получает проблему при чтении, проблема совершенно несвязана с собственно чтением (понятно - блок типа прочитался, но потом при работе в нем такие данные, что дальнейшими действиями по неправильным пойнтерам засрался весь сегмент и начали происходить странные вещи). Разработчик пробует воспроизвести - не воспроизводится (ибо сбой не постоянный). Разработчик очень упорный, он думает, тестирует, проводит неделю за компом и находит ключ. Ставит валидацию - проблема решена. Это очень плохой вариант. А если разработчик ставит - "не воспроизводится" и забивает - вот это вот мы переходим к полному 3.14ецу. Ибо теперь мы передаем продукт клиенту, клиент ставит его на не очень хорошие компы/линии и то, что у нас в лабе бывало раз в три года, у него бывает раз в месяц. И в один нехороший месяц прочиталась такая фигня, что убила всю систему и данные. Фирма разоряется, все разработчики свободны. ;)
 13.0.782.22013.0.782.220
BG Реконструктор #14.09.2011 11:30  @Mishka#13.09.2011 19:44
+
-
edit
 
вообще-то bb |= 0x00000001; и bb |= 0x80000000; всегда делают то, что ты ожидал, вне зависимости endianess. Тоесть то, что bb.firstBit = 1; транслируется либо в одно, либо в другое - это вряд ли.
 6.0.26.0.2
RU yacc #14.09.2011 12:13  @Сергей-4030#13.09.2011 17:55
+
+1
-
edit
 

yacc

старожил
★★☆

Сергей-4030> Вы просто не въезжаете. Вы такого не видели никогда в своем плюсном мире - берем хороший такой проект, с развитым UI, с хорошей серверной частью, работающий на PC, копируем файлы на Мак (не перекомпилируем даже) - и вуаля, все тут же работает. На плюсах до такого плыть и плыть.
Только сначала озаботившись постановкой JRE специально для этого проекта, бо на компе могут быть другие проекты, использующие JRE другой версии :)
Ага, баги в JRE тоже есть :)
... особенно это весело, когда проект живет на машине заказчика годами и ты его саппортишь, а баг, скажем, лечит замена JRE на более свежую...
Аналогичные "проблемы" я сейчас вижу у дот-нетчиков.
Вот в С++ я такого не видел.
 3.6.203.6.20
+
-
edit
 

Balancer

администратор
★★★★★
digger> printf vs sys.print.out

printf vs write

Вообще, не понимаю, как можно спорить о качестве продукта при столь малом знании о нём?



Кстати, тебе Форт должен, наверное, нравиться. Там оператор печати самый короткий — просто точка :)
"Hello, world" .
 
+
-
edit
 

Balancer

администратор
★★★★★
digger>> printf vs sys.print.out
Mishka> М-да. А когда можно использовать printf? А не знаком, что надо в Джаве, чтобы не писать sys? А что такое namespace в C++ не знаком? И как в C++ с namespace работают?

Ну да. В Си++ сегодня printf — вообще моветон :)std::cout << ... сегодня норма жизни. Так что наш оппонент от мейнстрима Си++ отошёл примерно в моё время :) (я тоже писал ещё printf'ы… Но было это 15 лет назад)
 
+
-
edit
 

Balancer

администратор
★★★★★
digger> Как вы будете МZ header или другую структуру например загружать в Жабу?

Ну, вот практический пример:
PacketHandler.java
handlePacket() получает сырые байтовые данные из бинарного сетевого протокола. Потом — хэндлеры в духе clientpackets/Action.java разбирают полученный поток на запчасти (целые, байты, плавающие, строки):
code java
  1. public Action(ByteBuffer buf, ClientThread client)
  2. {
  3.     super(buf, client);
  4.     _objectId = readD();
  5.     _originX = readD();
  6.     _originY = readD();
  7.     _originZ = readD();
  8.     _actionId = readC(); // 0 for simple click  1 for shift click
  9. }
 
RU Balancer #14.09.2011 14:02  @Реконструктор#14.09.2011 11:30
+
-
edit
 

Balancer

администратор
★★★★★
Реконструктор> всегда делают то, что ты ожидал
code cpp
  1. int i = 5;
  2. std::cout << i++ + ++i;

что будет в результате? :)
 

Balancer

администратор
★★★★★
yacc> ... особенно это весело, когда проект живет на машине заказчика годами и ты его саппортишь, а баг, скажем, лечит замена JRE на более свежую...
yacc> Аналогичные "проблемы" я сейчас вижу у дот-нетчиков.
yacc> Вот в С++ я такого не видел.

Тут есть пара моментов:

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

2. Бинарник, полученный с помощью Си++ жёстко привязан к платформе и вопрос глюков на другой платформе вообще не вспывает. Оно там просто работать не будет. Требуются исходники и дальше — пункт 1.
 
BG Реконструктор #14.09.2011 14:49  @Balancer#14.09.2011 14:04
+
-2
-
edit
 
Balancer> Тут есть пара моментов:
Balancer> 1. На Си++ легко получить неработоспособную программу при сборке нового бинарника на другую платформу или даже при смене опций компиляции.
Balancer> 2. Бинарник, полученный с помощью Си++ жёстко привязан к платформе и вопрос глюков на другой платформе вообще не вспывает. Оно там просто работать не будет. Требуются исходники и дальше — пункт 1.

Платформено-зависимая функциональность (обычно написана на C) джавы изолирована от основной логики в отдельный модуль. Что и положено всем нормально спроектированным программам, вкл. C++. Если нужного модуля нет - "переносимость" джавы накрывается тазиком. Просто для джава дивелопера это невидимо, что и приводит к фантазиям о т.наз.переносимости.
 6.0.26.0.2
1 2 3 4 5 6 7

в начало страницы | новое
 
Поиск
Поддержка
Поддержи форум!
ЯндексЯндекс. ДеньгиХочу такую же кнопку
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru