Google разрабатывает язык Noop для замены Java

> Потому что нет ни С++ для микроконтроллеров, ни С++ в ядре ОС, да!

Хм, а я то, наивный, думал, что L4 на C++, да ещё и для embedded предназначено...

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

4.2 Выделение памяти под жабой ГОРАЗДО ДЕШЕВЛЕ, чем через malloc. Не в курсе? Бегом читать про перемещающие и генерационные сборщики мусора.

Освобождение дорого только тогда, когда у объекта есть деструктор. Это большая редкость.

> H-файл дает возможность быстро просмотреть функциональность модуля, не читая его код.

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

> С++, по сравнению с C, дал возможность применить ООП, не замедляя результат

То есть, попытались прикрутить высокоуровневые концепции, но язык при этом оставить низкоуровневым. Поэтому-то результат и кошмарен.

> Java, по сравнению с C++, увеличивает код, замедляет результат.

4.2 Жабокод в среднем существенно короче. Не говоря уже о том, что гораздо читабельнее. А если уж использовать более современные инкарнации, типа C# 4.0, ууу...

> 2) Четкая стандартная библиотека. Насколько я понимаю, кол-во frameworks на Java уже к десятку подходит?

Как связаны фреймворки и стандартная библиотека? Как раз стандартная библиотека у Java/DotNet "чёткая", а вот у С++...

Вообще, baverman поставил довольно непростую задачу.

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

Но я не требовал результата для всего множества натуральных чисел. Достаточно в рамках сишных примитивов. А если кто-нибудь реализует для n <= 50, то честь тому и хвала.

На питоне я управился за минуту.

#!/usr/bin/env python

import sys

def fact(n):
    result = 1
    while n > 1:
        result *= n;
        n -= 1

    return result


print fact(int(sys.argv[1]))

> Выделение памяти под жабой ГОРАЗДО ДЕШЕВЛЕ, чем через malloc.

Бгг. Те, кому нужно скоростное выделение/освобождение памяти на Си/Си++, используют пулы.

> Хм, а я то, наивный, думал, что L4 на C++, да ещё и для embedded предназначено...

Вот я тоже не пойму, зачем им там С++ (на который они переехали сразу с асма, минуя Си?) Видимо, сказались лихие 90-ые... Впрочем, значительная часть разработок там в основном на x86 ориентированы, и коммерческое^W практическое использование весьма небольшое.

30! по размеру занимает больше 8 байт (максимальный размер данных в С++, не считая не целочисленные типы float, double и long double). А та прога:

#include <math.h> #include <stdio.h>

double get_infininty() { return exp(1e10); }

double factorial(unsigned n) { double res = 1; if(n <= 1) return res; else if (n > 300) return get_infininty(); else while(n) res *= n--; return res; }

int main() { printf("%.0f\n", factorial(30)); }

выдаёт у меня 265252859812191070000000000000000, что в общем то с определённой погрешностью (не забываем, тип double) даёт правильный ответ - 2,6525285981219105863630848e+32. погрешность составляет 10%. Теперь покажи свой аналогичный код на жабе, и давай сверимся? Кстати, если у тебя там неправильный результат почему то получается - достань руки из жопы.

>То есть, попытались прикрутить высокоуровневые концепции, но язык при этом оставить низкоуровневым. Поэтому-то результат и кошмарен.

Это не баг, это фича!

> 4) Практика показала что даже OpenGL работает сильно по разному под виндой и под линуксом, не верите?

4.2. за исключением системно-специфичных Extensions и функций работы с окнами (создание, уничтожение и обработка событий, которые всё таки ОЧЕНЬ похожи, чтоб их даже чайники могли осилить) всё работает 1-в-1. Ну или вариант "руки из жопы растут" просто.

> Для любого человека "знающего и любящего математику, решающего задачи на уровне составления матмоделей", не составит труда решить неравенство "fact(n) < 2^32", хотя бы и методом Ньютона.

Опять неверно. Откуда ж вы такие уверенные беретесь. Просто диву даюсь. hint: sizeof(unsigned). В коментариях было дано очень точное правило. Видимо для плюс-плюс-кунов существует только одна платформа.

> Пока не дашь свою реализацию, будешь сидеть голодный.

Чуть выше уже.

> Cтарались, писали программы

Мало старались, пока выходит только УГ.

> сомнительны плюсы определения типа переменной по типу rvalue в присваивании. по итогу в настоящих программах переменные будут присваиваться в стиле var x = (int) 2.

Обоснуйте. А лучше, поинтересуйтесь, как дела обстоят в C# и OCaml.

> уважамый, Вы нихерена не поняли, вопрос не за качество, а за скорость... давайте уже подключайте моск

ну насчёт скорости - я уже писал, тут жаба работает быстрее С/С++ только в блогах и параллельных вселенных. А скорость разработки - зависит от прогеров. Быдлокодерам конечно быстрее будет на жабе. Ведь можно абстрагировать шо песдетс, не заниматься памятью (авось она бесконечная), и применять костыли типа Garbage Collector. В итоге получится говнокод с нихуёвыми тормозами. На С++ можно всё тоже самое, но можно и лучше, просто сейчас полно быдлокодеров и индусов, которые его не осилили.

> Ну дык приведи пример

Насчёт делегирования средствами языка - почитайте про Tcl + snit

> Представьте что у Вас под виндой ribbon есть, как Вы реализуете его под linux?

легко и просто:

http://pic.co.ua/images/1253437504280ae65ac4ed7273eb17194cf2002b8a.png

> выдаёт у меня 265252859812191070000000000000000

А у меня 265252859812191104246398737973248

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

> у с++ теперь новая стандартная либа - QT4 :)

Кстати да. Ещё один пример, когда хорошая обёртка спасает плохую технологию.

> На С++ можно всё тоже самое, но можно и лучше, просто сейчас полно быдлокодеров и индусов, которые его не осилили

Я-то в советское время о-о-о...

Почему люди непременно должны совершать ежедневные подвиги?

>> Пока не дашь свою реализацию, будешь сидеть голодный.

>Чуть выше уже.

Ну дал ты реализацию на питоне, а на жабе?

>Вот я тоже не пойму, зачем им там С++ (на который они переехали сразу >с асма, минуя Си?) Видимо, сказались лихие 90-ые...

С этим согласен. Плюсы там совсем без надобности.

> Впрочем, значительная часть разработок там в основном на x86 > ориентированы, и коммерческое^W практическое использование весьма > небольшое

А вот тут не согласен. Как минимум порт на ARM существует, и приходиться с ним работать. Так что, коммерческое^W практическое использование (с) налицо, с нашей колокольни естественно. Большего утверждать не возьмусь.

> В то время как в тех языках, где мусорщика нету или он имеет ограниченный функционал (C, C++, Perl и др.), в документации сразу говорится, что за объектом/функцией/переменной надо следить, освобождать память, как и когда надо, и, как и когда не надо.

Что дядька Кнут говорил про предварительную оптимизацию?

30! = 265252859812191058636308480000000

Это так в качестве референсного значения.

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

>> выдаёт у меня 265252859812191070000000000000000

>А у меня 265252859812191104246398737973248

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

а ты на жабе код покажи. про питон я и слова не говорил, зелёный.

>>Ну-тко приведи мне аналог виндовых заданий (jobs) в линуксе, а то мож я уже чего пропустил?

>Растолкуй, что есть вендовый job - может, и приведем.

http://msdn.microsoft.com/en-us/library/ms684161(VS.85).aspx

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

>Это уже давно не совсем так. Или совсем не так - зависит от точки зрения.

то есть Ричард Стивенс и Стивен Раго подло врут, да? или Вы не знаете кто это?

> Ну дал ты реализацию на питоне, а на жабе?

Жаба в этом отношении так же ужасна как C++. У нее нет такой абстракции как число.

>>Вот я тоже не пойму, зачем им там С++ (на который они переехали сразу с асма, минуя Си?) Видимо, сказались лихие 90-ые...

> С этим согласен. Плюсы там совсем без надобности.

Просто интересно - ты правда считаешь себя более квалифицированным, чем авторы L4?

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

абстракцию тоже надо поддерживать и развивать... и как раз там формируются платформозависимые ветки кода (о коих мы и говорили) -> круг замкнулся :)

я так и делаю, а там где это возможно использую интерпретируемые языки и не парюсь :)

>> Это уже давно не совсем так. Или совсем не так - зависит от точки зрения.

> то есть Ричард Стивенс и Стивен Раго подло врут, да?

Скорее, они просто ошибаются.

> или Вы не знаете кто это?

Это авторы старых учебников по программированию.

>> Ну дал ты реализацию на питоне, а на жабе?

> Жаба в этом отношении так же ужасна как C++. У нее нет такой абстракции как число.

ну вот, значит жаба по этому пункту не лучше С++, ЧТД. А на питона мне строго пох.

> абстракцию тоже надо поддерживать и развивать...

оставьте это разработчикам сторонних библиотек

>А он при использовании Java плачевен - громоздкие и медленные программы.

Хватит ахинею нести, поставь себе lobobrowser и зайди на http://www.linux.org.ru/view-message.jsp?msgid=4057338 убедись, что Lobo летает быстрее Chrome

> Просто интересно - ты правда считаешь себя более квалифицированным, > чем авторы L4?

Нет конечно :) Из C++ специфичных фич, в L4 я разглядел(плохо смотрел?) только перегрузку операторов, да и то не в самом ядре а в обёртке для прикладного уровня. Так что вполне логичный вывод, IMHO.

> http://msdn.microsoft.com/en-us/library/ms684161(VS.85).aspx

Не понимаю, зачем использовать это в переносимых программах, но это явно содрано с юниксовой session.

кстати, забыл добавить. для системно-независимой работы с окнами есть куча библиотек: glut, QT, fltk, наверняка ещё что-нить найдётся.

> Хватит ахинею нести, поставь

я вот кстати недавно редактор отчетов писал - у меня вся отрисовка практически мгновенная, в том числе при "живом" растягивании и перемещении, подскажи мне пример на Java, который при таких же операциях( на большом листе с множеством объектов на разных уровнях ) не тормозил

>> Хватит ахинею нести, поставь

> я вот кстати недавно редактор отчетов писал - у меня вся отрисовка практически мгновенная, в том числе при "живом" растягивании и перемещении, подскажи мне пример на Java, который при таких же операциях( на большом листе с множеством объектов на разных уровнях ) не тормозил

ща тебе напишет, что в каком-то блоге писали, что жаба не тормозит, и даже выигрывает у С/С++ по скорости.

>> 4) Практика показала что даже OpenGL работает сильно по разному под виндой и под линуксом, не верите?

>4.2. за исключением системно-специфичных Extensions и функций работы с окнами (создание, уничтожение и обработка событий, которые всё таки ОЧЕНЬ похожи, чтоб их даже чайники могли осилить) всё работает 1-в-1.

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

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

> http://en.wikipedia.org/wiki/Mixin

Это такое множественное наследование для бедных.

> QT, fltk, наверняка ещё что-нить найдётся.

ну как минимум еще wxWidgets, я вообще свой тулкит на базе fltk написал, т.к. его базовой функциональности мне не хватало, а такой реактивной отрисовки больше ни у кого нет

>ну говорю ж, не сталкивался ты с серьёзными проектами, поэтому у тебя всё просто :)

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

Да да, в работе со сферическо-вакуумными серьёзными проектами постоянно какая-то куйня происходит.

>насчет автоматического выделения памяти. это банальная автоматизация malloc/free освобождающая программисту время и силы

# Garbage Collection is just easier to use than malloc/free. This is well documented in the industry (I'm blithely ignoring all the C/C++ hand-rolled memory management techniques like "arenas" or "resource areas"; these fall into the category of "malloc/free is so hard to use so we rolled our own poor-mans GC but if the language had GC we would probably have never bothered").

# GC allows for entirely different algorithms, isn't just easier to use than malloc/free. Many concurrent algorithms are very easy to write with a GC and totally hard (to down right impossible) using explicit free. Reference counting is commonly used in these situations in C/C++ but it adds a lot more overhead (sometimes a *lot* more overhead) and is much harder to get right: e.g. a common mistake is keeping the count in the structure being guarded.
# Very Good Multi-Threading Support. Parallel programming is just easier in Java.

>> уважамый, Вы нихерена не поняли, вопрос не за качество, а за скорость... давайте уже подключайте моск

>ну насчёт скорости - я уже писал, тут жаба работает быстрее С/С++ только в блогах и параллельных вселенных.

Да что ж Вы такой буратина то, а? Ещё раз: мы разговариваем о скорости разработки, comprende?

И да, раз Вас так это заботит, погуглите "насичёт" java-процессоров.

>А скорость разработки - зависит от прогеров.

Никто и не спорит. Буржуи же, которые умеют считать деньги, давно подсчитали, что при прочих равных скорость разработки на Java/Python/whatever выше, чем на C++.

>Быдлокодерам конечно быстрее будет на жабе.

Причём тут быдлокодеры казалось бэ? Вы сам на любом скриптовом языке хоть один коммерческий проект выполняли?

>Ведь можно абстрагировать шо песдетс, не заниматься памятью (авось она бесконечная), и применять костыли типа Garbage Collector.

Ну и к чему этот высер? Вы не знаете шо такое GC? Вижу - не знаете, это понятно. Только вот причём тут память бесконечная поясните?

>у меня вся отрисовка практически мгновенная, в том числе при "живом" растягивании и перемещении

Приложение служит для растягивания и перемещения себя? А чтонибудь полезное оно делает?

> Ну дал ты реализацию на питоне, а на жабе?

Для каждой задачи свой язык :))))))

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

>> Представьте что у Вас под виндой ribbon есть, как Вы реализуете его под linux?

>легко и просто: http://pic.co.ua/images/1253437504280ae65ac4ed7273eb17194cf2002b8a.png

так... и для этого Вы буду использовать один и тот же код или всё-таки разные ветки?

И да, учтите что под "вендой" ribbon чаще всего реализуется с применением mfc.

>> Ну дал ты реализацию на питоне, а на жабе?

>Для каждой задачи свой язык :))))))

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

>так чтобы мат модели там были и зарплата поболе чем 10 долларей?

За матмодели зарплату не платят, а за mail.ru и вконтактах платят

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

Все это понятно. Я хотел показать вот какую вещь. Новички в C++ просто до невозможности беззаботны. Язык дает им иллюзию высокоуровневости, иллюзию защищенности от подлых железок. Я ее нет. И ждать неоткуда. Это тот же коварный зловещий Си, только с безумно сложными классами. Подаванов учат ООП c использованим C++, но совершенно забывают рассказать, что каждый пук должен быть проверен. А потом эти умельцы приходят на производство. И впоследствие, что самое интересное, виноваты мифические индусы.

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

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

один и тот же

> И да, учтите что под "вендой" ribbon чаще всего реализуется с применением mfc.

никогда не писал на mfc - и не собираюсь