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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ага-ага

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Нет, не OLAP. OLTP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

x = Ынтырпрайз

> doWhatIWant() и doItFaster(doWhatIWant)

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

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

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

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

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

> . http://golang.org/ хомячок как бы символизирует

Это хомячок кого надо хомячок.

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

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

> В Go есть garbage collection.

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

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

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

> от 2 до 20 на большинстве задач

нет - не от 2 до 20, ну и в среднем получается разница в 61 раз

>> В Go есть garbage collection.

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

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

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

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

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

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

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

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

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

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

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

И да, чем тебе не угодил GArray?

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

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

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

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

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

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

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

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

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

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

Не?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Встроенность регэкспов вовсе не подразумевает тормоза на уровне 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

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

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

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

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

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