LINUX.ORG.RU

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

 , , ,


0

2

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

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

★★★★★

Проверено: mono ()
Последнее исправление: MuZHiK-2 (всего исправлений: 2)

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

>Сравни объем Кернигана-Ритчи и любого талмуда по крестам или жабе

А теперь сравни с талмудом по Brainfuck.

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

> годная распределенная СУБД

В общем то распределенную СУБД можно писать на чем угодно, что имеет низкоуровневый доступ к системному API.

У распределенными СУБД есть одна очень важная проблема - передача данных по сети.

Нельзя гарантировать возможность записи в СУБД в случае отказа каналов передачи данных.

Сеть отвалилась и привет.

И что только не пытались придумать, но воз и ныне там.

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

>>да, конечно :) кто бы спорил, с точки зрения синтаксиса - да

С точки зрения понимания - тоже. Сравни объем Кернигана-Ритчи и любого талмуда по крестам или жабе (они зачастую вообще многотомные).

вопросов нет, всё так

>>и да, на Си трудно написать нормальный контейнер для хранения данных, в glib, например, сплошные костыли

ну давай, пример парочки костылей в студию.

открываем сорцы glib, заходим в поддиректорию glib-<your version>/glib, открываем garray.h (garray.c) и навскидку сравниваем с тем как это сделано в std::vector, бурно и продолжительно чещем затылок

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

А после Руби...

[quote]Почему скорость написания программы важнее скорости ее выполнения? Ответ заключается в следующем вопросе: вам платят за результат, который достигнут в срок или за качество, которое достигнуто с опозданием? Печально, но программистам (как и переводчикам) платят за скорость написания кода, а не за его качество и скорость выполнения. Если скорость выполнения программы вполне приемлема (не идеальна, а приемлема), то, скорее всего, заказчика это устроит. Если заказчику необходим быстро работающий код, то он явно укажет это в задании, но даже в этом случае, сначала будет написана работоспособная программа и лишь потом она будет оптимизироваться по быстродействию. Иначе, программа может не быть написана вообще! Вот именно поэтому код стоит писать быстро. И только, если он будет неприемлемо медленный, его нужно будет переделать (оптимизировать), и, возможно, делать это будете не вы, а программисты, которые специализируются на подобного рода задачах. Есть над чем задуматься? Rubynovich, 30 мая 2006 [/quote]

ага-ага

unt1tled ★★★★
()

>назвав их многословными

ололо. этот троллинг от автора Go, у которого:
- чтобы объявить функцию надо написать func
- чтобы объявить переменную надо написать var
- ну и ":=" в качестве присвоения.

тьфу, толсто как! убрали скобки в некоторых операторах, и теперь пытаются хвалиться лаконичностью. еще раз тьфу.

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

Ну не все же такие школота, как ты.

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

>>Давным-давно циклов не было. Они реализовывались в виде флагов и условных переходов. Писать большие программы в таких условиях было невозможно. Придумали языки более высокого уровня (сейчас их имеет смысл называть языками среднего уровня). В них добавили циклы. Это было большим развитием для того времени. Но циклы имели все недостатки, присущие своим предкам: одна ошибка — и цикл завершался не начавшись или зацикливался (выполнялся бесконечно). А человеку свойственно ошибаться. Затем придумали разные контейнерные типы данных, например коллекции объектов. Использовать цикл для коллекций было не совсем удобно, поэтому придумали для них итераторы, которые работали только с элементами коллекции.

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

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

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

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

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

> многие лоровцы забывают о том, что «Преждевременная оптимизация — корень всех зол в программировании» (с) и для любой задачи выбирают нечто компилируемое в нейтив.

толсто - http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=...

java до в 214 раз быстрее

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

>>открываем сорцы glib, заходим в поддиректорию glib-<your version>/glib, открываем garray.h (garray.c) и навскидку сравниваем с тем как это сделано в std::vector

Исходники glib я видел. Причем тут крестовые контейнеры? Ты сказал, что GArray сделан через костыли. Я теперь прошу тебя конкретно указать, где там ты увидел костыли, но ты пытаешься отбрехаться, тыкая в кресты. Я так могу сравнить любой язык с другим и сказать, что тут одни костыли. Давай, показывай конкретно.

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

> Однако преждевременная оптимизация гораздо большее зло чем отсутствие оптимизации. А преждевременная оптимизация болезнь многих сишников

см. выше, и да - не стоит считать что на С все начинают с оптимизации

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

> Нет, не OLAP. OLTP

Говорить про абстрактный сферический OLTP в вакууме бессмысленно.

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

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

>java до в 214 раз быстрее

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

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

> Сравни объем Кернигана-Ритчи и любого талмуда по крестам или жабе

Это так, игрушка.


brainfuck - крохотный «талмуд» - игрушка
C - средний «талмуд» - хороший язык
Java - большой «талмуд» - X

задача найти Х?

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

Хотя да, там где применаются регэкспы руби всего в 2 раза тормознее но с учетом того что код пишется быстрее раз в 20... =)))

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

>>открываем сорцы glib, заходим в поддиректорию glib-<your version>/glib, открываем garray.h (garray.c) и навскидку сравниваем с тем как это сделано в std::vector

Исходники glib я видел. Причем тут крестовые контейнеры? Ты сказал, что GArray сделан через костыли. Я теперь прошу тебя конкретно указать, где там ты увидел костыли, но ты пытаешься отбрехаться, тыкая в кресты. Я так могу сравнить любой язык с другим и сказать, что тут одни костыли. Давай, показывай конкретно.

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

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

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

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

> doWhatIWant() и doItFaster(doWhatIWant)

и интерфейс пользователя выглядит так

большая зеленая кнопка - при нажатии вызвается функция doWhatIWant

+ ручка как у динамо-машины если хочешь чтобы быстрее считалось - начинаешь ее крутить.

так что я бы определил вторую функцию просто как doItFaster() - при ее вызове программа ускоряется в 2 раза на время 100 мсек.

при вращении ручки будет постоянно (раз в 100 мсек) вызываться функция doItFaster()

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

>java до в 214 раз быстрее

от 2 до 20 на большинстве задач, а три последние - чистая числодробилка, для числодробилок нет ничего лучше фортрана

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

>> В Go есть garbage collection.

Майн готт, все в машину!


А если серьезно, так в этом какбэ смысл в том числе.


Привет, я Йнтерпрайз и мне без тормозов нельзя.

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

На интересных мне задачах разница в 2-3 раза

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

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

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

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

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

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

Используй GValue и прекрати газификацию.

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

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

DNA_Seq ★★☆☆☆
()

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

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

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

То есть ты запрещаешь сравнивать языки между собой?

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

>>И? Ты же предложил сравнивать по размеру талмудов.

А теперь сравни скорость написания кода и издержки при разработке на брейнфаке. Если ты не заметил, я сравнил языки высокого уровня.

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

На давно известных языках писались давно известные программы слишком простые по нынешним временам

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

>>То есть ты запрещаешь сравнивать языки между собой?

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

MuZHiK-2 ★★★★
()
Ответ на: А после Руби... от unt1tled

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


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

Не?

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

>>То есть ты запрещаешь сравнивать языки между собой?

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

Это и есть сравнение языков. То, чем занимается Пайк.

tailgunner ★★★★★
()

> слишком замысловаты

Он это высер обосновал?

И когда Андроид на педоне будет? Бу-га-га-га-га! :)

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

Bioreactor ★★★★★
()

Говорит Ананимус. И посему говорит правду. Дело, как известно, не в желании, и даже не в умении. И программят программы на С++/Жабе вместо Го не потому, что всем это всё нравится больше, чем учить Го, а потому что НАДО. Потому что куда приткнуть это ваше что-то новое, чтоб деньги за него платили? Никуда. Потому что Страуструп не по свовей воле сделал С++ вместо Simula++ или Smalltalk++. А потому что НАДО БЫЛО. Никуда теперь не деться от C/C++/Java-достояния.

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

Пусть переписывает, главное чтоб был рабочий прототип. К тому же в угаре вы забыли об одноразовых и часто переписываемых программах. А такие программы тоже нужны

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

>>Это и есть сравнение языков. То, чем занимается Пайк.

То, что он тонко потроллил - ежу понятно.

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

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

>>Т.е. ты признаешь, что размер ничего не значит? (гусары, молчать)

Размер чего? А то ты любишь потом слова пристраивать к любому контексту.

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

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

Встроенность регэкспов вовсе не подразумевает тормоза на уровне Ruby.

val lor_uri_pattern = """http://www.linux.org.ru/forum/(.*)/(\d*)\?lastmod=(\d*)""".r
val uri = "http://www.linux.org.ru/forum/talks/5149211?lastmod=1279977175866"
uri match {
    case lor_uri_pattern(section, id, lastmod) => //do something
}

Вариант 2:

val lor_uri_pattern = """http://www.linux.org.ru/forum/(.*)/(\d*)\?lastmod=(\d*)""".r
val uri = "http://www.linux.org.ru/forum/talks/5149211?lastmod=1279977175866"
val lor_uri_pattern(section, id, lastmod) = uri
//do something

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

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

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

Я уже отписался - на задачах с регэкспами Руби всего в 2 раза тормознее что можно объяснить тормозной реализацией регэкспов в жабе

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

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

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

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