LINUX.ORG.RU

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

 ,


1

0

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

Noop говорит ДА:

  • Внедрению зависимостей в языке
  • Тестируем ост
  • Неизменяемости
  • Синтаксису направленному на улучшение читабельности кода
  • Никогда не устаревающей документации
  • Свойствам, сильной типизации и разумной современной библиотеке

Noop говорит НЕТ:

  • Любой статике
  • Наследованию (subclassing)
  • Примитивам
  • Ненужным шаблонам

Исходные коды доступны под Apache Licence 2.0

>>> Google urges developers to get in loop with Noop

★★☆☆

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

Ответ на: комментарий от lester

> думаю стоит проверить - можете плз написать сюда полный пример кода на Java

Проверял уже - когда писал диплом, у меня программа на С генерировала файл с графами, а на Java - его анализировала. Размеры файлов - десятки гигабайт.

Скорость анализа упиралась только в производительность НЖМД.

Ну или можете поискать скорость индексации lucene.

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

> В случае GC-языка вы можете просто написать bar(foo())

да и С/C++ можно, если возвращать не указатель

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


а еще есть smart_ptr

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

> Вы получили быструю приближённую реализацию и стали ныть, что она "нетакая", хотя, не сомневаюсь, ни разу не прочитали _все_ цифры полученного вашим чюдопитоном числа.

А у тебя по какой причине засвербило? Вроде достаточно адекватный программист, судя по постам.

> приближённую

Меня учили в таких случаях указывать погрешность, иначе результат неверен.

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

> Это обращение к системе, через вызов, гц же выделяет свой пул( гораздо меньше обращений), и аллокация может сводится к увеличению указателя. Освобождение тоже может быть оптимизировано при помощи перестановок, что уменьшит и фрагментацию.

но ведь такое же можно сделать на С++ (если ещё не сделано), а вот в жабе отказаться от GC можно?

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

> Скорость анализа упиралась только в производительность НЖМД

да-да, а код на С и Java выполнялся абсолютно мгновенно :)

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

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

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

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

> ну допустим ограничение не в 64 бита, но оно всё равно есть.

Да, ограниченная память. И всё. Другое вас волновать не должно.

> Только в С++ они не встроены в язык, и их можно достать отдельно, а в питоне они встроены. разницы минимум.

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

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

> В случае GC-языка вы можете просто написать bar(foo()), и у вас после выполнения этой комбинации автоматически подчистится и промежуточная ABC, и все её вложенные структуры.

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

а нельзя написать bar(c=foo()), а затем delete(c), где c - функция, удаляющая ABC? или наш быдлокодер такое уже не может осилить?

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

> да и С/C++ можно, если возвращать не указатель

Хрен там. Даже если структура на стеке, в ней могут быть ссылки на объект на куче, который может быть перехвачен кем-то ещё. Без GC эта задача в общем случае нерешаема.

> а еще есть smart_ptr

Ну поздравляю, вы таки задействовали свой собственный GC, только очень примитивный и требующий осторожного обращения. Велосипедистам привет!

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

> Почитайте описание ассемблера 8086; там вполне себе были инструкции для работы с 32-разрядными целыми.

А пример можно? Не могу вспомнить ни одной инструкции для работы с 32-разрядными данными

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

необоснованный баттхерт? давай ищо

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

> что в любом случае при освобождении нужно что-то делать с фрагментацией

Кстати, ещё одна задача, которую нельзя адекватно решить без GC и управляемых ссылок.

> гц приходится считать ссылки,

Не всегда. Учите матчасть.

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

описался, не c - функция удаления ABC, а delete

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

> Вывод: важен язык и знание основ

[отмахнувшись] любой императивный язык учится за неделю; язык другой парадигмы - за две недели. Главное - основы.

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

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

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

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

> а нельзя написать bar(c=foo()), а затем delete(c), где c - функция, удаляющая ABC?

Читайте выше. Внутри ABC может быть много всего интересного.

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

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

Ага, Си++ за неделю :D

> язык другой парадигмы - за две недели.

Доо, Хаскель за 2 недели %)

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

> [отмахнувшись] любой императивный язык учится за неделю

C++ за неделю? Либо он не императивный, либо вы 3.14здеть изволите, сударь.

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

> Хрен там. Даже если структура на стеке, в ней могут быть ссылки на объект на куче

это уже задача деструктора, либо того же smart_ptr

> Ну поздравляю, вы таки задействовали свой собственный GC, только очень примитивный и требующий осторожного обращения.


в большинстве случаев даже smart_ptr не нужен, так что его "примитивность" вами преувеличена - он просто делает свою работу

lester ★★★★
()

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

Где-то мы это уже видели. Pl/1?

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

>вот у меня спллчекер проверяет английский и русский одновременно.

>спллчекер

класно же он проверяет, однако!

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

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

А в рантайме твой C++ компилить не может P-)

I compiled the C++ version with 'g++ *cpp' and the java version as 'javac *java'.

int sum=0;
for (int i = 0; i < max; i++)
sum += val(); // virtual call
return sum;

Here I run it on the same X86:

> a.out 1000000000 0
1000000000 adds in 2.657645 secs
> java vcall 1000000000 0
1000000000 adds in 0.0 secs

The Java code is "infinitely" quick: after JIT'ing the -server compiler essentially deduces a closed-form solution for the answer and can report the correct result with a few bits of math... no looping. This example is ridiculous of course, but it points out the obvious place where dynamic compilation beats static compilation. This "make a virtual call into a static call" optimization is a major common frequent optimization JIT's can do that static compilers cannot.

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

>Кстати, ещё одна надуманная задача, которая не сушествует без GC и управляемых ссылок.

fixed

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

>но ведь такое же можно сделать на С++ (если ещё не сделано), а вот в жабе отказаться от GC можно?

Зачем мешать разный уровень абстракции?

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

> А пример можно? Не могу вспомнить ни одной инструкции для работы с 32-разрядными данными

А при чем здесь ассемблер и сишный примитив?

Всем, всем, всем. Было очень забавно. Очень много радости принесли. Мне пора начинать писать плагин к gedit для редактирования xml. На питоне :) Думаю за 10 часов справлюсь.

Милым, забавным крестникам желаю скорейшего просветления.

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

> А пример можно? Не могу вспомнить ни одной инструкции для работы с 32-разрядными данными

Скажем так, там были МЕХАНИЗМЫ ОБЛЕГЧЕНИЯ работы с 32-битными данными.

MUL, DIV - произведение и делимое 32-битные. Если делитель или сомножитель 32-битные - то в три этапа, со сдвигами.

Сложение и вычитание делается в два этапа: ADD+ADC, SUB+SBB.

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

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

"У верблюда два горба

Потому что жизнь БОРЬБА!"©

Мы в совке живем, не забывай, каждый день, это подвиг

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

> А в рантайме твой C++ компилить не может P-)

как будто от этого программы на Java становятся быстрее :)

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

> это уже задача деструктора, либо того же smart_ptr

Ну вот видите, как только сложная ситуация - нужно прикручивать GC. А когда он всегда под рукой - то и нет промблем :]

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

>Читайте выше. Внутри ABC может быть много всего интересного.

И что же там может быть такого интересного, с чем у тебя без GC не получается разобраться? Хотя если у тебя конкретно... то там может быть ВСЁ, быдлокодер.

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

>> Ага, Си++ за неделю :D Доо, Хаскель за 2 недели %)

> При хорошей подготовке-то? Леххко.

При любой подготовке. Смишно.

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

>> Числа с точкой - время 1000000 вычислений в секундах. Бигинт на 50000% тормознее. Так и весь питон на столько же тормознее плюсов.

>Я правильно понял - ты сравниваешь _приближенное_ вычисление факториала в плавающем формате, и _точное_ - в целочисленном формате, и на основании этого делаешь выводы о сравнительной скорости Си++ и Питона?

Питон (как нам тут скромненько так продемонстрировал щекастый тролль) считает факториал _точно_. И вообще все числа всегда он считает точно. Если на плюсах считать факториал точно, то получается медленно. Питон не может иметь существенно более быстрый способ вычислений, чем c++. Т.е. все числа всегда он считает _медленно_.

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

Дебилко анонимное, проблема фрагментации памяти существует ТОЛЬКО для языков без перемещающих GC. Учи матчасть.

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

>>Malloc - это очень дорого.

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

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

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

>> приближённую

>Меня учили в таких случаях указывать погрешность, иначе результат неверен.

Тип данных double - это и есть указание погрешности.

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

> Т.е. все числа всегда он считает _медленно_.

Смотря какой. Третий - да. Второй - нет, там было разделение короткой и длинной арифметики.

А вообще, если вам надо быстро считать на питоне много чисел - то к вашим услугам NumPy и Cython.

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

Ололо, зелёный быдлокодер. Как раз такую проблему придумали, чтобы оправдать применение GC. "Наш новый GC решает нашу новую проблему".

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

>т.е. виноват не С++, а сложность?

т.е. виноват с++ который не может справиться с таким проектом без полного переписывания.

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

Анонимное дебилко, ты сходи почитай что такое "фрагментация памяти" и в каких случаях malloc говорит "out of memory". Поумнеешь - приходи, поговорим.

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

> Питон (как нам тут скромненько так продемонстрировал щекастый тролль) считает факториал _точно_.

Ну ты на вопрос ответь, если ты сам не такой щекастый.

> Т.е. все числа всегда он считает _медленно_.

Питон ровно так же, как и Си++, может посчитать факториал в double. Про какое "всегда" ты говоришь - я просто не понимаю.

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