LINUX.ORG.RU

Google дал оценку Java и C++

 , , ,


0

2

Один из ведущих инженеров Google — Роб Пайк (Rob Pike) — выступил на конференции O'Reilly Open Source Convention (OSCON) и выразил мнение корпорации о современных языках разработки и месте C++ и Java в них. Он отозвался об этих индустриальных китах очень негативно, назвав их многословными, чрезмерно сложными и неадекватными к применению в решении задач современной компьютерной инфраструктуры.
«Я думаю, что эти языки слишком сложны для использования, слишком трудны для понимания, слишком замысловаты. Они очень многословны, их сложность, громоздкость и непонятность возрастают со временем», — заявил Роб.

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

★★★★★

Проверено: mono ()

Ответ на: комментарий от MuZHiK-2

при том что я с ними сравниваю :) у тебя возражения?

Как ты можешь сравнивать одно в одном языке с другим в другом языке и кричать, что первое - костыль?

легко могу сравнивать :) неужели ты мне в этом праве отказываешь, на каком основании? или ты не знал что так можно? :)

>>конкретно смотри на GArray, GByteArray, GPtrArray

Я видел их. Я пользовался ими.

мне кажется ты забыл капсом дописать «МНЕ ОНИ НРАВЯТСЯЯЯ!!!!!!11адинадин АРРРГГГХХХ!»

Теперь, уже в третий раз, спрашиваю тебя: покажи КОНКРЕТНО, где там костыли.

хм, думал будет понятно ещё прошлый раз, ну раз непонятно - копаем глубже

struct _GArray
{
  gchar *data;
  guint len;
};

struct _GByteArray
{
  guint8 *data;
  guint	  len;
};

struct _GPtrArray
{
  gpointer *pdata;
  guint	    len;
};

ничего не смущает?

и, как следствие:

GArray* g_array_new(/*blah*/);
GPtrArray* g_ptr_array_new(/*blah*/);
GByteArray* g_byte_array_new(/*blah*/);

здесь тоже ничего не смущает???

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

>>Талмудов. Или ты ещё о чём-то подумал?

Почему не значит? Повторю тебе опять: ты сравнил эзотерическую хрень с языками высокого уровня.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от MuZHiK-2

>ты сравнил эзотерическую хрень с языками высокого уровня.

Ты сравнил основываясь просто на размере. Это, значит, не хрень? Какой пузатик. Если язык умеет больше, например, то и талмуд будет больше. Также зависит от автора (стиля текста). Так тоже не ясно?

Deleted ()

Роб дело говорит, хоть и попаболь у ЦПЛЮСПЛЮСеров с ЖАВАфилами

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

> хоть и попаболь у ЦПЛЮСПЛЮСеров с ЖАВАфилами

и не говори - просто на говно исходят

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

легко могу сравнивать :) неужели ты мне в этом праве отказываешь, на каком основании? или ты не знал что так можно? :)

Можно много чего, но это не означает трезвость ума.

ничего не смущает?

Нет, потому что все реализации сделаны на основе GArray. Для удобства использования API. Но никто не мешает тебе все время пользоваться GArray - на здоровье. Только ты, сынок, забыл посмотреть ВСЮ реализацию GArray перед тем, как метанировать. Потому что если бы ты ее посмотрел, то увидел бы, что вся работа идет через другую структуру - общую для всех тобой указанных:

struct _GRealArray
{
  guint8 *data;
  guint   len;
  guint   alloc;
  guint   elt_size;
  guint   zero_terminated : 1;
  guint   clear : 1;
  volatile gint ref_count;
};

здесь тоже ничего не смущает???

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

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от Deleted

>>Если язык умеет больше, например, то и талмуд будет больше. Также зависит от автора (стиля текста). Так тоже не ясно?

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

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от MuZHiK-2

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

И потерять все проверки компилятора на совпадение типов. Ты вообще не в своем уме, или тупо троллишь?

tailgunner ★★★★★ ()
Ответ на: комментарий от MuZHiK-2

Однако если язык умеет слишком мало, то см. пример с Brainfuck'ом. Сравнивать по размеру талмуда — глупость.

Deleted ()
Ответ на: комментарий от MuZHiK-2

> Талму́д (ивр. תָלְמוּד‎, «учение, учёба») — многотомный свод правовых и религиозно-этических положений иудаизма

Евреи не одобряют ваш разговор.

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

Предлагаешь считать бинарные деревья и множества Мандельброта на мобилках? Да ты упоротый!

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от tailgunner

>>И потерять все проверки компилятора на совпадение типов. Ты вообще не в своем уме, или тупо троллишь?

А ты в своем? Я же не говорю использовать GArray напрямую там, где УЖЕ используются другие типы. Я говорю о том случае, когда ты на пути первоначального выбора, что использовать.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от MuZHiK-2

> volatile gint ref_count;

сборка мусора через подсчет ссылок удивляет

sign ()
Ответ на: комментарий от MuZHiK-2

> Я же не говорю использовать GArray напрямую там, где УЖЕ используются другие типы. Я говорю о том случае, когда ты на пути первоначального выбора, что использовать.

Хм. Похоже, не в своем.

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

>>Хм. Похоже, не в своем.

Как всегда, аргументированно.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от sign

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

А что удивительного? В GObject это обычное дело, хотя GArray и не относится к нему.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от MuZHiK-2

> Как всегда, аргументированно.

Напиши мне выборку элемента из _GRealArray.

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

>>Однако если язык умеет слишком мало, то см. пример с Brainfuck'ом. Сравнивать по размеру талмуда — глупость.

Причем тут мало умеет? Я сравнил языки высокого уровня, брейнфак к ним не относится.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от shty

и да, раз уж ты такой умный, предложи способ написания обобщённого контейнера в Си :) мне это нужно, да


Просто. Береж java.collections, пишешь свой код, компилишь, берешь javap, смотришь полученный байткод, переносишь на C. профит

Karapuz ★★★★★ ()
Ответ на: комментарий от MuZHiK-2

>Я сравнил языки высокого уровня

Ты так говоришь, как будто это что-то меняет.

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

>>Напиши мне выборку элемента из _GRealArray.

GRealArray - это приватная структура, описанная в garray.c, а потому не доступная для работы из вне. Непонятно, где ты собрался ее применять. На ее основе сделаны GArray, GPtrArray и GByteArray.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от Deleted

>>Ты так говоришь, как будто это что-то меняет.

Ты так говоришь, будто писать на асм и жабе - одно и то же.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от MuZHiK-2

> GRealArray - это приватная структура, описанная в garray.c, а потому не доступная для работы из вне. Непонятно, где ты собрался ее применять.

Афигеть %) Пациент путается в показаниях. Это ты сказал вот эту глупость:

ты всегда можешь напрямую для всех целей использовать GArray.

напрямую

для всех целей использовать

Я с удовольствием посмотрю, как ты будешь выпутываться :D

tailgunner ★★★★★ ()
Ответ на: комментарий от MuZHiK-2

>>ничего не смущает?

Нет, потому что все реализации сделаны на основе GArray. Для удобства использования API.

а меня смущает, потому что удобство API - это всё хорошо, но для пользователя, а в моём случае API писать буду я и три раза писать одно и то же - это застрелиться и не встать

Вы таки не поняли что дело не в критике glib, она то как раз хорошая, к ней вопросов нет :) критика к тому что приходится писать постоянно кучу подпорок, например Вы видели что происходит внутри gvarianttype (а отнюдь не gvalue как Вы предлагали) - это застрелите меня что там происходит и так со всем и везде

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

Только ты, сынок

ты это, рамсы чёт совсем попутал, давай полегче тут, не дома на диване

Только ты [..] забыл посмотреть ВСЮ реализацию GArray

struct _GRealArray 
{ 
  guint8 *data; 
  guint   len; 
  guint   alloc; 
  guint   elt_size; 
  guint   zero_terminated : 1; 
  guint   clear : 1; 
  volatile gint ref_count; 
};

во-первых не забыл, просто движение должно осуществляться поступательно

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

вкратце вот такие, я считаю, недостатки у языка си и это мешает мне применять его во многих проектах

shty ★★★★★ ()
Ответ на: комментарий от MuZHiK-2

непомешало бы иметь конструкторы и деструкторы в glib для их динамических объектов а то помимо glib в функции надо освободить ресурсы так еще приходится и следить чтоб вся память из по этих в кавычках динамических структур была освобождена в итоге не код а одно осовождение ресурсов получается

osox ()

Один из ведущих инженеров Google

s/Один из ведущих инженеров Google/Один из ведущих быдлокодеров Google

PS ниже эпичная новость: «ffvp8 уделал оригинальный гугловский декодер, будучи еще на довольно раней стадии разработки»

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

>>Афигеть %) Пациент путается в показаниях. Это ты сказал вот эту глупость:

Ты упоротый что ли? GArray и GRealArray - это две разных структуры. Я ничего не спутал. Ты хоть glib видел в глаза, или так, пометанировать захотелось? Ты можешь при желании использовать GPtrArray и GByteArray, но (!), если тебя в них что-то не устраивает, ты ВСЕГДА для ВСЕХ целей можешь воспользоваться более общим вариантом - GArray. GRealArray был приведен к метанированию о костылях в реализации другого пациента.

Я с удовольствием посмотрю, как ты будешь выпутываться :D

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

MuZHiK-2 ★★★★ ()

У инженеров Гугл ЧСВ овер 9000 по умолчанию.

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

> Ты упоротый что ли?

Я - нет, а ты?

GArray и GRealArray - это две разных структуры.

Напиши мне выборку элемента любого типа, кроме char, из любого из них.

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

>>а меня смущает, потому что удобство API - это всё хорошо, но для пользователя, а в моём случае API писать буду я и три раза писать одно и то же - это застрелиться и не встать

Используй GArray и не парь людям мозги.

критика к тому что приходится писать постоянно кучу подпорок, например Вы видели что происходит внутри gvarianttype (а отнюдь не gvalue как Вы предлагали) - это застрелите меня что там происходит и так со всем и везде

Где эти подпорки? Если ты называешь подпорка то, что в glib прикрутили ООП - то это твои проблемы, что ты не осилил ООП и тебе хочется быдлокодить на крестах и джабе.

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

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

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от osox

>>непомешало бы иметь конструкторы и деструкторы в glib для их динамических объектов а то помимо glib в функции надо освободить ресурсы так еще приходится и следить чтоб вся память из по этих в кавычках динамических структур была освобождена в итоге не код а одно осовождение ресурсов получается

Беги на жабу.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от tailgunner

>>Я - нет, а ты?

Нет, а ты?

Напиши мне выборку элемента любого типа, кроме char, из любого из них.

Она уже 10 лет назад была написана - посмотри в исходниках glib g_array_index ().

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от sign

Да ее можно сделать вообще на чем угодно.

Проблема в том, что мне нужен язык, у которого есть такая сущность как память. У явы, например, нет. У Плюсов с stl тоже ее нет. И как тут жить?

У erlang, кстати, тоже, как и у haskell.

catap ★★★★★ ()
Ответ на: комментарий от MuZHiK-2

а меня смущает, потому что удобство API - это всё хорошо, но для пользователя, а в моём случае API писать буду я и три раза писать одно и то же - это застрелиться и не встать

Используй GArray и не парь людям мозги.

неужели не понятно, что использовать glib не всегда возможно?

Где эти подпорки? Если ты называешь подпорка то, что в glib прикрутили ООП - то это твои проблемы, что ты не осилил ООП и тебе хочется быдлокодить на крестах и джабе.

какие то взаимоисключающие параграфы ни о чём - пропускаем

Ты так и не объяснил, в чем заключается костыльность данной реализации.

костыльность в чём? - в костылях,а в чём же ещё

когда Вы поучаствуете в написании достаточно большого проекта на си с нуля в котором нельзя будет использовать GPL/LGPL код и всё это будет в условиях существенно ограниченного времени (а так оно так практически всегда), то я верю что у Вас таких вопросов больше возникать не будет

shty ★★★★★ ()
Ответ на: комментарий от MuZHiK-2

>будто писать на асм и жабе - одно и то же.

Не угадал. goto start

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

>>неужели не понятно, что использовать glib не всегда возможно?

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

костыльность в чём? - в костылях,а в чём же ещё

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

когда Вы поучаствуете в написании достаточно большого проекта на си с нуля в котором нельзя будет использовать GPL/LGPL код и всё это будет в условиях существенно ограниченного времени (а так оно так практически всегда), то я верю что у Вас таких вопросов больше возникать не будет

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

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от Deleted

>>Не угадал. goto start

Зациклился? Не переживай, бывает.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от MuZHiK-2

неужели не понятно, что использовать glib не всегда возможно?

По лицензионным или техническим аспектам?

а что, есть какая-то разница?

Если ты пеняешь в С на то, что в нем ничего нет по умолчанию - это другое дело.

это только первая часть марлезонского балета, вторая часть - в языке отсутствуют свойства которые бы позволяли гибко работать на описанном уровне

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

нужно эти 3 показателя иметь сбалансированными :) и замедлять разработку путём выбора неправильного ЯП - это называется ССЗБ

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

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

а если нет нужного велосипеда - что тогда? а я скажу - сидеть и есть кактус, надеясь что успеешь

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

ниже эпичная новость: «ffvp8 уделал оригинальный гугловский декодер, будучи еще на довольно раней стадии разработки»


Очевидно же, в гугле просто не занимались преждевременной оптимизацией, а писали код, который хоть както декодирует VP8

А вот когда они перепишут его на Go.....

Karapuz ★★★★★ ()
Ответ на: комментарий от MuZHiK-2

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

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

> А вот когда они перепишут его на Go.....

самому не смешно?

anonymous ()
Ответ на: Re: А после Руби... от Karapuz

>И этот специалист возьмет ваш код, покачает головой, поцокает языком и скажет «не-не-не, мне дешевле переписать это все с нуля, чем оптимизировать отдельные участки»

Согласен. Я этот отрывок запостил как ржаку над всей этой руби-викой. Как вообще можно писать программу не имея перед собой плана или алгоритма, оптимизирующего работу.. Так только на руби наверно и пишут :)

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

tailgunner> И нас всех спасет Go?

Goсподу-у-у помолимся-а-а, братия-а-а.

sdio ★★★★★ ()

Не дезинформируйте людей: это не гугл дал оценку, а Роб Пайк.

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

>> И нас всех спасет Go?

Goсподу-у-у помолимся-а-а, братия-а-а.

ЛММ не даст нас в обиду, спасет от маразматика Пайка и его дебильного кролика %)

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