567 читателей, 34 поста
Администрация
Модераторы
Популярным языкам — по блогу. Остальным посвящается…
Языки программирования whois
- индекс
- 130,38
Google Go = Python и C++
Google только что объявил выпуск нового языка с открытым исходным кодом
под названием Go. Компания говорит что, Go эксперементальный язык и
он объединяет производительность и безопасность компилируемых языков(как С++)
со скорость разработки динамических языков (как Python).
Оффициальный талисман языка GO — суслик:
Для подробностей смотрим http://golang.org/
Для низкого старта вот как выглядит Hello World в GO:
под названием Go. Компания говорит что, Go эксперементальный язык и
он объединяет производительность и безопасность компилируемых языков(как С++)
со скорость разработки динамических языков (как Python).
Оффициальный талисман языка GO — суслик:
Для подробностей смотрим http://golang.org/
Для низкого старта вот как выглядит Hello World в GO:
package main
import fmt “fmt” // Package implementing formatted I/O.
func main() {
fmt.Printf(”Hello, world; or Καλημέρα κόσμε; or こんにちは 世界n”);
}
комментарии (168)
Не забывайте, что главное не синтаксис, а семантика. Этот язык поддерживает динамическую типизацию, а питон был упомянут как один из самых известных динамически типизированных языков.
>Без эксепшенов, шаблонов и с очень странной и ограниченной моделью классов.
В С++ часто пишут без исключений, и ничего. Да и от классов далеко не все в восторге. Зато нативная поддержка программных потоков и вообще конкурентной парадигмы. Все имеет свои преимущества и свои недостатки. Ваш КО.
А нет же! напридумывали ddr, а потом ddr2 и тп
Когда-то писали на коболе и фортране, теперь java
Когда появляются на мировой арене такие языки, как ruby и python, мир становится красивее, совершенее.
Вполне идея гугла может провалиться, но вдруг из этого вырастет что-то хорошее )
Пускай делают, вам же жить это не мешает ))
Зато билдится шустро =)
Хм, почему? В обероне, например, есть GC.
Это для Гугл.
Видимо, их устраивает не все.
Про язык D в Google, конечно же, не слышали
[/sarcasm]
Мне кажется, в последнее время каждый уважающий себя программист придумывает очередной язык программирования или пишет ещё одну программу, делающую то же самое, что и сотни аналогичных, только «лучше». Я не против прогресса, я против велосипедостроения.
— PHP (Python, Perl, Ruby, Java, ...)
— SQL
— HTML + CSS — по сложности и замороченности верстки это можно вынести в отдельный язык
— Javascript
Ничуть, просто я говорю к тому, что такой зоопарк уже стал нормой.
>> Если люди понимают задачи, думают как их решать и используют для этого удобные инструменты поддерживаемость только растёт
С такими прописными истинами не поспоришь, это правда. А еще можно усилить и добавить — «если команда сильная, то и продукт получится», «если менеджер понимает, что он делает — мы не опоздаем со сроками», «если вовремя учитывать риски, то можно их минимизировать»… /* бормоча эти заклинания, скрывается за углом */
…
/* выглядывает назад */
Только как это все помогает понять предмет статьи, то что вы сказали?
Нет.
> А еще можно усилить и добавить — «если команда сильная, то и продукт получится», «если менеджер понимает, что он делает — мы не опоздаем со сроками», «если вовремя учитывать риски, то можно их минимизировать»… /* бормоча эти заклинания, скрывается за углом */
Это бред согласен, но его связи со своим высказыванием не прослеживаю.
> Только как это все помогает понять предмет статьи, то что вы сказали?
Да никак, также как процентов 50 комментариев тут :)
Но гугл развитая компания, у которой менеджмент поставлен на высоком уровне. Эта компания не будет тратить деньги на изобретение велосипеда.
Эволюция идет, да бывают ошибочные ветки, но все равно развитие есть.
Гугл уже однажды перевернул мир, может это получится еще раз, пускай не этим проектом )
Но, кто не пытается — тот не обламается ))
Хо-хо-хо! Эта компания будет тратить деньги на любые велосипеды по политическим соображениям.
Как ещё можно назвать переписывание с нуля libc для Linux? =)
Где там велосипедостроение? Можете назвать реально юзабельный ЯП для системного программирования, кроме Си и Си++? (Ди неюзабелен, к сожалению, также, как и Cyclone).
O RLY? Почему же тогда тогда на golang.org/ написано
>Go
>a systems programming language
И статья пестрит гиперболами. Не делайте из мухи слона. Если в D и есть проблемы, они не вечны. Это справедливо для любого мало-мальски серьёзного проекта, и для D тоже.
Индуктивный аргумент.
>Если в D и есть проблемы, они не вечны.
Не вечны, да, но за три года их так и не решили. А теперь уже поздно.
>Это справедливо для любого мало-мальски серьёзного проекта, и для D тоже.
Разброд, шатание и общая сломанность — это справедливо для каждого проекта?
И считается ли нехватка человекоресурсов разбродом и шатанием?
А D более-менее вменяем, поддерживает C-библиотеки, почему бы не пользоваться? Несмотря на все недостатки из статьи.
Велосипедостроения? А что плохого в объединении хороших сторон разных языков в одном? Главное ведь чтоб удобно было, хоть и 25-й велосипед по счету.
— я писал: ---
Объединение не подразумевает выкидывание хорошо себя зарекомендовавших технологий современных ЯП: ООП, исключений, шаблонов.
Чем Python не угодил? Сделайте статическую типизацию, оптимизирующий компилятор (по сути, только back-end), и voila! — быстро компилируемый и быстро исполняемый язык готов.
А как же D? Куча наработок типа удобоваримых шаблонов, приятного синтаксиса, качественная стандартная библиотека, пусть ещё и в стадии разработки; почему бы не помочь довести до ума то, что ещё не доведено и пользоваться.
Но нет, «D/Python/что_угодно не нужен, мы сделаем свой язык, с блэкджеком и шлюхами, можно грабить корованы». ChromeOS — кусок Linux с гуглобраузером, теперь вот Go — огрызок от большого арбуза современных ЯП. Ещё велосипеды? Не хочу!
>Объединение не подразумевает выкидывание хорошо себя зарекомендовавших технологий современных ЯП: ООП, исключений, шаблонов.
Потеря ООП и шаблонов не фатальна. Зато в Go есть интерфейсы, это что-то вроде классов типов, если я правильно понял. Очень мощный инструмент.
>Чем Python не угодил? Сделайте статическую типизацию, оптимизирующий компилятор (по сути, только back-end), и voila! — быстро компилируемый и быстро исполняемый язык готов.
Если бы все было так просто :) Системы типов разные бывают, и не факт что любая из них хорошо подойдет для языка с возможностью прямого доступа к памяти.
>А как же D? Куча наработок типа удобоваримых шаблонов, приятного синтаксиса,
Да никуда D не денется. Это ведь кибернетика, а не биология, тут идеи не умирают. :)
>качественная стандартная библиотека
Точнее, целых три, две из которых делались урывками, и потому едва ли качественные. :)
«An interface is a pointer to a struct. The struct has three fields. The first field is a pointer to the type descriptor for the dynamic type of the object. The second field is a pointer to a table of methods for the interface to be used with the object. The third field is the value of the object itself.» ©gccgo branch by Ian Lance Taylor :)
есть уже, perl6 называется :)
Simple, Unladen Swallow, Go. Что будет дальше?
За Go поддержка такой махины, как Google, и это аргумент (линк на статью о проблемах развития D как бы говорит). Но на уровне концепций языка, по-моему, D выигрывает с большим преимуществом.
Мир несправедлив, увы: )
Это смотря зачем вам нужен язык :) Для десктопов возможно он и лучше, а вот зато для создания масштабируемых серверных приложений Go вне конкуренции.
Там этому достаточно внимания уделено :)
… concurrent
Go promotes writing systems and servers as sets of lightweight communicating processes, called goroutines, with strong support from the language. Run thousands of goroutines if you want—and say good-bye to stack overflows.
Поищите по ключевым словам Communicating Sequential Processes, Newsqueak и Limbo, что ли.
Подытожу то, что хотел сказать в самом начале:
* когда я читаю о фишках D, я думаю «чёрт побери, это именно то, что мне не хватало в _языке_».
* когда я читаю о фишках Go, я думаю «это отличная штука, но это всё реализуется на уровне библиотеки для любого достаточно низкоуровневого языка» *(по ключевым словам поискал и изучил в меру своего понимания)
Поэтому мне несколько обидно, что _язык_ проигрывает _технологиям_.
Да, я тоже так думал, когда познакомился с D :)
>Поэтому мне несколько обидно, что _язык_ проигрывает _технологиям_.
Мне кажется, это проявление того самого worse is better, о котором говорил Richard Gabriel.
А излишняя лаконичность, увы, часто выливается в нехватку мощностей и обилие костылей.
В, скажем, Java (поправьте если ошибаюсь), есть лаконичность системы типов вида «всё есть объект». Это красиво, но что делать, если, чёрт побери, мне _не нужен_ объект? Нехватка мощности.
Лаконичность синтаксиса в контексте C++ как-то странно звучит… По количеству БНФ выражений в стандарте он один из рекордсменов.
Java имеет свои проблемы от желания быть «и в райкоме и в раю», Smalltalk, Ruby, Python и ещё куча языков прекрасно живут с моделью «всё объект».
Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. ©
Вообще, это достаточно естественное противостояние между языками, предоставляющими максимум фич и языками, стремящимися к лаконичности. Это как перл и питон.
Как показывает пример питона, лаконичный язык вовсе не обязательно ведёт к «костылям».
Но в целом ваш комментарий выглдяит очень правдоподобно, с ним даже не хочется спорить :)
Я тут всех за Cython агитирую — с ним Python-овую программу можно лёгкими оптимизациями довести по производительности до C-шной. Приэтом зачастую не вылезая из совместимости с интерпретатором Python-а.
Мне лично мусоросборщик не нужен. В С++ у меня нет проблем с потерянными new/delete. Особенности используемого фреймворка. Поэтому ещё один поток для сборки мусора — лишняя сущность, особенно в силу особенностей задач (промышленная автоматика) заведомо неизвестным образом увеличивающая время реакции системы.
Если интересно, знакомство можно начать вот с этой ссылки:
ultimatepp.org/www$uppweb$overview$en-us.html
Ну-ну, расскажите-ка, как такое возможно?
В общем, я думаю, что эти штуки должны где-то на уровне языка поддерживаться а не писаться сверху и нести оверхед. Тогда компилятор мог бы использовать оптимизации, например предотвратить клонирование объекта и вызов retain/release при передаче его в функцию, если он больше не используется, пример:
void func () {
Object a(); // refcount = 1
someFunc(a); // создается и передается копия a, а можно было бы передать оригинал
…
// здесь освобождается a
}
Дело в том, что фреймворк использует свои контейнеры, которые позволяют очень быстро и эффективно работать с объектами. Если не вдаваться в подробности, в коде почти полностью отсутствуют new и полностью — delete. Делается это за счёт «стекового» объявления членов. При этом сами контейнеры уничтожают объекты в своём деструкторе.
Я позволю себе процитировать часть описания, в котором кратко описана идеология тех вещей, о которых я говорил выше:
"Everything belongs somewhere
In Ultimate++, most objects are bound to some logical scope. As a result, you will not see many new operators in code using Ultimate++ and almost no delete operators outside the implementation of containers.
That of course does not mean you are not allowed to use pointers, but it is good practice to use pointers just to point to things, never to manage heap resources. This also avoids all confusion regarding ownership of the underlying object, time of its deletion etc. If you need to manage data sets of variable size or polymorphic type, you should prefer using one of Ultimate++ containers.
Speaking about it, there are no shared smart pointers (like boost::shared_ptr) in Ultimate++ used to manage heap resources at interface level. They are not needed and considered bad practice.
In C++, this approach proves to be equally good or better than garbage collected languages like Java or C#. While those languages are able to provide automatic management of heap resources, U++ approach provides very deterministic automatic management of all resources.
Ultimate++ containers
One aspect of Ultimate++ is bringing a lot of criticism: Ultimate++ is not using much of standard C++ library. There are, however, serious reasons for this. STL, with its devastating requirement that each element stored in container has to have copy-constructor, makes standard containers somewhat hard to use in GUI development.
There is no such general requirement for Ultimate++ containers. Instead, Ultimate++ containers come in two flavors.
Vector flavor has Moveable requirement that allows very fast implementation for certain types (e.g., element insertion at arbitrary position of Ultimate++ Vector is more than 10 times faster than the same operation with typical implementation of std::vector<std::string>).
Array flavor has no requirements for element types at all, at the price of somewhat lower performance.
As a result, in Ultimate++ you are for example allowed to create container of .GUI widgets that edits integer numbers ( Array integer_editors) and even sort it using standard Ultimate++ Sort algorithm. Doing something like this would require using pointers as elements in STL (std::vector<EditInt *>) or alternatively some sort of smart pointers (soon to be std:: boost::shared_ptr), but both increase code complexity and break the Ultimate++ rule according to which everything belongs somewhere."
www.ultimatepp.org/srcdoc$Core$Moveable$en-us.html
www.ultimatepp.org/srcdoc$Core$PickTypes$en-us.html
www.ultimatepp.org/srcdoc$Core$pick_$en-us.html
(ссылки придётся открывать вручную, они неверно парсятся)
Т.е. использование фреймворка сильно уложняет и без того сложный C++ :(
Что касается сложности: действительно, U++ агрессивно использует некоторые подвинутые вещи в С++ и требует достаточно высокой квалификации программиста. Т.е. фреймворк обладает выоским цензом на вхождение и достаточно крутой кривой обучения. Но взамен же вы получаете возможность писать крайне эффективные кросс-платформенные приложения без утечек памяти и некоторых прочих недостатков.
То есть, в идеале, чтобы избавляться от лишних deep copy при возврате занчений из функции не использвоанием Pick, а чтобы компилятор все это прозрачно делал :)
Будем ждать, вдруг кто напишет?
в си можно выбирать какой будет оверхед(смартпоинтеров много разных), а решения встроенные в язык обеспечивают полный оверхед всегда. Ведь там решают проблемы, которых нет в большинстве случаев.
>на каждую операцию типа передачи объекта в функцию, вызываются методы retain/release
зачем так неразумно использовать умные указатели?
>someFunc(a); // создается и передается копия a, а можно было бы передать оригинал
Это си? Имелось в виду использование стэка func() в someFunc()? надеюсь уже поняли что это бред :)
> зачем так неразумно использовать умные указатели?
Что значит, зачем?
Вот в таком коде:
SmartPointer smartpointer(...);
someFunc(smartPointer);
smartPointer передается по значению, так? Значит — создается новый объект, точнее копия, и передается в функцию в кач-ве фактического параметра. Вот и оверхед.
По поводу оверхеда: во всех распространенных языках с управлением памяти есть такой же или похожий оверхед, связанный с трекингом ссылок (например, в .net присваивание ссылок будет чуть дольшим, чем просто копирование адреса) — ну кроме консервативного Boёhma, наверное.
Это не значит, что smart pointer-ы чем-то хуже. Это значит, что тупо бесплатных вещей не бывает.
Эээ, а как тогда будет refсount считаться и память освобождаться? Не, это ненраильный способ.
Но выше ведь обсуждали _возможные_ оверхеды. Так что в этом частном случае, если функция его никуда не передает, можно отдавать константный smart_pointer либо вообще голый pointer (smart для единообразия).
Я прокомментировал только вот эту вашу фразу: «SmartPointer передается по значению, так? Значит — создается новый объект, точнее копия, и передается в функцию в кач-ве фактического параметра».
Так что из кода, который приведен, совсем не следует, что будет оверхед.
Если передавать копию — конечно будет оверхед, но это плата за то, что вы его куда-то (смартпойнтер) собираетесь передаыть/копировать/разделять
struct X {
};
std::vector< boost::shared_ptr > xs;
void foo(const boost::shared_ptr & x) {
xs.push_back(x);
}
Это будет нормально работать.
Я вот одного не понимаю. Зачем рассуждать о том, устройства чего не понятны.
habrahabr.ru/blogs/programming/74913/#comment_2168911
если интересно.
Кстати, существуют реализации GC реального времени.
(Хотя, замыкания, которые нельзя вернуть из функции все-таки трудно назвать «полноценными» ;)
ATS это Applied Type System, диалект Dependent ML: www.ats-lang.org
Точно — это же из серии Plan 9. Знакомьтесь, Glenda:
Потому что Go — от авторов Plan 9
Q: What kind of a name is 6g?
A: The 6g (and 8g and 5g) compiler is named in the tradition of the Plan 9 C compilers, described in plan9.bell-labs.com/sys/doc/compiler.html (see the table in section 2). 6 is the architecture letter for amd64 (or x86-64, if you prefer), while g stands for Go.
По поводу С подобного синтаксиса.
Мне приходилось писать на питоне, и честно говоря, жесткое форматирование исходного кода и разделение блоков отступами не очень радовало. Были моменты, когда я сам не понимал, что написал:
for i in 10:
a = a + 1
b = a * 2
Из-за случайного сдвига строчки с b, иногда вынужден заново просматривать алгоритм. Так что фигурные скобки мне очень сильно помогают. В гугле всегда говорили, что хорошо читаемый код для них одно из главных требований.
Ну и в конце концов, поддержка от такого гиганта скажется на популярности языка.
И кстати, число не итерабельно. :-)
for (i = 1; i <= 15; i+c[i]){ a = a+b[15]} b = a * 2Питоном он от этого не станет.
Все равно это C, у которого {{много:: ненужных;; символов_и_слов}}; и:: вообще(читать) {невозможно}.