Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 168
маскот = талисман.
Плохо, что нет поддержки Windows
Google потихоньку завоевывает мир…
Вот если бы они его сделали еще и по виду, как питон, без этих скобочек, цены бы им не было :)
Что-то не могу понять, где там рядом валялся питон. Судя по туториалу, это си-образный язык со странноватым синтаксисом и плюшками в «современном» стиле такими, как вывод типов. Без эксепшенов, шаблонов и с очень странной и ограниченной моделью классов. Но зато компилятор очень быстрый (что и продемонстрировано в ролике, а больше ничего не продемонстрировано).
Хмм, а зачем нужен еще один язык? Лично меня итак все устраивает.
когда-то людям хватало пары килобайт озу ))
А нет же! напридумывали ddr, а потом ddr2 и тп
Когда-то писали на коболе и фортране, теперь java
Когда появляются на мировой арене такие языки, как ruby и python, мир становится красивее, совершенее.
Вполне идея гугла может провалиться, но вдруг из этого вырастет что-то хорошее )
Пускай делают, вам же жить это не мешает ))
А нет же! напридумывали ddr, а потом ddr2 и тп
Когда-то писали на коболе и фортране, теперь java
Когда появляются на мировой арене такие языки, как ruby и python, мир становится красивее, совершенее.
Вполне идея гугла может провалиться, но вдруг из этого вырастет что-то хорошее )
Пускай делают, вам же жить это не мешает ))
А Вы что, не в курсе? На страничке FAQ этого языка четко написано, зачем он нужен: "… За последние 10 лет не появилось ни одного нормального языка системного программирования, а ведь прогресс не должен стоять на месте!..." (вольный перевод, но суть сохранена).
[sarcasm]
Про язык D в Google, конечно же, не слышали
[/sarcasm]
Мне кажется, в последнее время каждый уважающий себя программист придумывает очередной язык программирования или пишет ещё одну программу, делающую то же самое, что и сотни аналогичных, только «лучше». Я не против прогресса, я против велосипедостроения.
Про язык D в Google, конечно же, не слышали
[/sarcasm]
Мне кажется, в последнее время каждый уважающий себя программист придумывает очередной язык программирования или пишет ещё одну программу, делающую то же самое, что и сотни аналогичных, только «лучше». Я не против прогресса, я против велосипедостроения.
Полностью согласен. Если уж делают язык, то пусть это будет такой язык, на который можно перейти для всех (ну, или 99%) разработок. Для меня таковым в свое время стал C#, для многих — Java. Изучать же каждые 6 месяцев новый язык можно, но применить его на практике все равно не получится, ибо заказчики не дураки и прекрасно понимают что поддерживаемость программы когда в нем даже 3 языка (скажем, C#, SQL & MDX) падает.
99% веб-проектов содержат 4 языка:
— PHP (Python, Perl, Ruby, Java, ...)
— SQL
— HTML + CSS — по сложности и замороченности верстки это можно вынести в отдельный язык
— Javascript
— PHP (Python, Perl, Ruby, Java, ...)
— SQL
— HTML + CSS — по сложности и замороченности верстки это можно вынести в отдельный язык
— Javascript
Поддерживаемость падает когда берётся default developer(студент-старшекурсник), default language(Java/C#/PHP), default architecture(3-layered — не лаптём щи хлебаем) и пишется в расчёте на диаграмму в квартальном отчёте, а не на функционал. Если люди понимают задачи, думают как их решать и используют для этого удобные инструменты поддерживаемость только растёт.
O, really? Какие громкие слова. Варианты недефолтовых настроек вы не рассматриваете — в смысле, не студент, не джава автоматом обеспечивают поддерживаемость?
>> Если люди понимают задачи, думают как их решать и используют для этого удобные инструменты поддерживаемость только растёт
С такими прописными истинами не поспоришь, это правда. А еще можно усилить и добавить — «если команда сильная, то и продукт получится», «если менеджер понимает, что он делает — мы не опоздаем со сроками», «если вовремя учитывать риски, то можно их минимизировать»… /* бормоча эти заклинания, скрывается за углом */
…
/* выглядывает назад */
Только как это все помогает понять предмет статьи, то что вы сказали?
>> Если люди понимают задачи, думают как их решать и используют для этого удобные инструменты поддерживаемость только растёт
С такими прописными истинами не поспоришь, это правда. А еще можно усилить и добавить — «если команда сильная, то и продукт получится», «если менеджер понимает, что он делает — мы не опоздаем со сроками», «если вовремя учитывать риски, то можно их минимизировать»… /* бормоча эти заклинания, скрывается за углом */
…
/* выглядывает назад */
Только как это все помогает понять предмет статьи, то что вы сказали?
>… в смысле, не студент, не джава автоматом обеспечивают поддерживаемость?
Нет.
> А еще можно усилить и добавить — «если команда сильная, то и продукт получится», «если менеджер понимает, что он делает — мы не опоздаем со сроками», «если вовремя учитывать риски, то можно их минимизировать»… /* бормоча эти заклинания, скрывается за углом */
Это бред согласен, но его связи со своим высказыванием не прослеживаю.
> Только как это все помогает понять предмет статьи, то что вы сказали?
Да никак, также как процентов 50 комментариев тут :)
Нет.
> А еще можно усилить и добавить — «если команда сильная, то и продукт получится», «если менеджер понимает, что он делает — мы не опоздаем со сроками», «если вовремя учитывать риски, то можно их минимизировать»… /* бормоча эти заклинания, скрывается за углом */
Это бред согласен, но его связи со своим высказыванием не прослеживаю.
> Только как это все помогает понять предмет статьи, то что вы сказали?
Да никак, также как процентов 50 комментариев тут :)
Да, вы правы, сейчас множество самоделок появляется на свет.
Но гугл развитая компания, у которой менеджмент поставлен на высоком уровне. Эта компания не будет тратить деньги на изобретение велосипеда.
Эволюция идет, да бывают ошибочные ветки, но все равно развитие есть.
Гугл уже однажды перевернул мир, может это получится еще раз, пускай не этим проектом )
Но, кто не пытается — тот не обламается ))
Но гугл развитая компания, у которой менеджмент поставлен на высоком уровне. Эта компания не будет тратить деньги на изобретение велосипеда.
Эволюция идет, да бывают ошибочные ветки, но все равно развитие есть.
Гугл уже однажды перевернул мир, может это получится еще раз, пускай не этим проектом )
Но, кто не пытается — тот не обламается ))
Преимущество работы в гугле — любой свой велосипед, сделанный за 20% времени, можно назвать «Google Bicycle» ;)
>Я не против прогресса, я против велосипедостроения.
Где там велосипедостроение? Можете назвать реально юзабельный ЯП для системного программирования, кроме Си и Си++? (Ди неюзабелен, к сожалению, также, как и Cyclone).
Где там велосипедостроение? Можете назвать реально юзабельный ЯП для системного программирования, кроме Си и Си++? (Ди неюзабелен, к сожалению, также, как и Cyclone).
ЭЭээ ATS? К сожалению, у него сырая реализация, да. Зато можно написать рантайм ATS полностью на ATS.
гм… писал несколько мелких приблуд на D. не заметил неюзабельности.
Во-первых, речь идёт о Go, который не для системного программирования.
>речь идёт о Go, который не для системного программирования.
O RLY? Почему же тогда тогда на golang.org/ написано
>Go
>a systems programming language
O RLY? Почему же тогда тогда на golang.org/ написано
>Go
>a systems programming language
Вопрос. Почему язык, позволяющий прямой доступ к памяти и точное задание расположения данных в памяти (data layout + padding) не подходит для системного программирования?
Во-вторых, D подходит для системного программирования. Никто никого не заставляет использовать сборщик мусора и исключительно высокоуровневые конструкции: есть поддержка указателей, встроенного ассемблера.
Я не говорил, что D не подходит для системного программирования. Я говорил о том, что он *неюзабелен*. По этому вопросу товарищем Jarrett Billingsley написана статья The Present of D.
Да что вы говорите? Для меня он более, чем юзабелен. Я на нём пишу утилиты для себя, а сейчас начал проект, использующий SQLite3, OpenSSL и wxWindows. Пока что всё получается. Если вы не можете писать на D, или он вас чем-то не устраивает, не геперболизируйте.
И статья пестрит гиперболами. Не делайте из мухи слона. Если в D и есть проблемы, они не вечны. Это справедливо для любого мало-мальски серьёзного проекта, и для D тоже.
И статья пестрит гиперболами. Не делайте из мухи слона. Если в D и есть проблемы, они не вечны. Это справедливо для любого мало-мальски серьёзного проекта, и для D тоже.
>Для меня он более, чем юзабелен.
Индуктивный аргумент.
>Если в D и есть проблемы, они не вечны.
Не вечны, да, но за три года их так и не решили. А теперь уже поздно.
>Это справедливо для любого мало-мальски серьёзного проекта, и для D тоже.
Разброд, шатание и общая сломанность — это справедливо для каждого проекта?
Индуктивный аргумент.
>Если в D и есть проблемы, они не вечны.
Не вечны, да, но за три года их так и не решили. А теперь уже поздно.
>Это справедливо для любого мало-мальски серьёзного проекта, и для D тоже.
Разброд, шатание и общая сломанность — это справедливо для каждого проекта?
Дык проблема, что D — пожалуй лучший вариант, из того что есть. C/C++ просто невозможно пользоваться — руки отвалятся, устаревший, громоздкий, провоцируюший-к-ошибкам синтаксис.
А D более-менее вменяем, поддерживает C-библиотеки, почему бы не пользоваться? Несмотря на все недостатки из статьи.
А D более-менее вменяем, поддерживает C-библиотеки, почему бы не пользоваться? Несмотря на все недостатки из статьи.
Как я понял, основная фишка Go — это поддержка concurrency на уровне языка со всеми вытекающими. Это серверный язык, если так можно выразиться и в этой области у него вряд ли есть конкуренты.
В Гугле таких програмистов несколько сотен.
Велосипедостроения? А что плохого в объединении хороших сторон разных языков в одном? Главное ведь чтоб удобно было, хоть и 25-й велосипед по счету.
Велосипедостроения? А что плохого в объединении хороших сторон разных языков в одном? Главное ведь чтоб удобно было, хоть и 25-й велосипед по счету.
Извините, тег [b] не закрыл
Хабр скушал сообщение. Приятного аппетита. Тем более, съел незакрытый тег (:
— я писал: ---
Объединение не подразумевает выкидывание хорошо себя зарекомендовавших технологий современных ЯП: ООП, исключений, шаблонов.
Чем Python не угодил? Сделайте статическую типизацию, оптимизирующий компилятор (по сути, только back-end), и voila! — быстро компилируемый и быстро исполняемый язык готов.
А как же D? Куча наработок типа удобоваримых шаблонов, приятного синтаксиса, качественная стандартная библиотека, пусть ещё и в стадии разработки; почему бы не помочь довести до ума то, что ещё не доведено и пользоваться.
Но нет, «D/Python/что_угодно не нужен, мы сделаем свой язык, с блэкджеком и шлюхами, можно грабить корованы». ChromeOS — кусок Linux с гуглобраузером, теперь вот Go — огрызок от большого арбуза современных ЯП. Ещё велосипеды? Не хочу!
— я писал: ---
Объединение не подразумевает выкидывание хорошо себя зарекомендовавших технологий современных ЯП: ООП, исключений, шаблонов.
Чем Python не угодил? Сделайте статическую типизацию, оптимизирующий компилятор (по сути, только back-end), и voila! — быстро компилируемый и быстро исполняемый язык готов.
А как же D? Куча наработок типа удобоваримых шаблонов, приятного синтаксиса, качественная стандартная библиотека, пусть ещё и в стадии разработки; почему бы не помочь довести до ума то, что ещё не доведено и пользоваться.
Но нет, «D/Python/что_угодно не нужен, мы сделаем свой язык, с блэкджеком и шлюхами, можно грабить корованы». ChromeOS — кусок Linux с гуглобраузером, теперь вот Go — огрызок от большого арбуза современных ЯП. Ещё велосипеды? Не хочу!
Тут уже выходим за пределы своей компетентности. :) Я, например, ни разу не специалист в проектировании языков программирования.
>Объединение не подразумевает выкидывание хорошо себя зарекомендовавших технологий современных ЯП: ООП, исключений, шаблонов.
Потеря ООП и шаблонов не фатальна. Зато в Go есть интерфейсы, это что-то вроде классов типов, если я правильно понял. Очень мощный инструмент.
>Чем Python не угодил? Сделайте статическую типизацию, оптимизирующий компилятор (по сути, только back-end), и voila! — быстро компилируемый и быстро исполняемый язык готов.
Если бы все было так просто :) Системы типов разные бывают, и не факт что любая из них хорошо подойдет для языка с возможностью прямого доступа к памяти.
>А как же D? Куча наработок типа удобоваримых шаблонов, приятного синтаксиса,
Да никуда D не денется. Это ведь кибернетика, а не биология, тут идеи не умирают. :)
>качественная стандартная библиотека
Точнее, целых три, две из которых делались урывками, и потому едва ли качественные. :)
>Объединение не подразумевает выкидывание хорошо себя зарекомендовавших технологий современных ЯП: ООП, исключений, шаблонов.
Потеря ООП и шаблонов не фатальна. Зато в Go есть интерфейсы, это что-то вроде классов типов, если я правильно понял. Очень мощный инструмент.
>Чем Python не угодил? Сделайте статическую типизацию, оптимизирующий компилятор (по сути, только back-end), и voila! — быстро компилируемый и быстро исполняемый язык готов.
Если бы все было так просто :) Системы типов разные бывают, и не факт что любая из них хорошо подойдет для языка с возможностью прямого доступа к памяти.
>А как же D? Куча наработок типа удобоваримых шаблонов, приятного синтаксиса,
Да никуда D не денется. Это ведь кибернетика, а не биология, тут идеи не умирают. :)
>качественная стандартная библиотека
Точнее, целых три, две из которых делались урывками, и потому едва ли качественные. :)
Каюсь, не уточнил. Я имел ввиду Phobos 2, и для развивающейся библиотеки она очень качественная. Я говорю о том, что она вполне юзабельна, а, если прилагать усилия, можно её улучшить (хотя бы писать багрепорты, что я и делаю время от времени).
>Зато в Go есть интерфейсы, это что-то вроде классов типов, если я правильно понял. Очень мощный инструмент.
«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 :)
«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 :)
Это же Гугл. Надеюсь у них выйдет что-то стоящее.
>Чем Python не угодил? Сделайте статическую типизацию, оптимизирующий компилятор (по сути, только back-end), и voila! — быстро компилируемый и быстро исполняемый язык готов.
есть уже, perl6 называется :)
есть уже, perl6 называется :)
Только недавно публика вновь вспомнила о таком мега-языке как D, а гугл уже подготовил ещё более вкусный ЯП. Однако.
Simple, Unladen Swallow, Go. Что будет дальше?
Simple, Unladen Swallow, Go. Что будет дальше?
Более вкусный? Мягко говоря, спорное утверждение: )
За Go поддержка такой махины, как Google, и это аргумент (линк на статью о проблемах развития D как бы говорит). Но на уровне концепций языка, по-моему, D выигрывает с большим преимуществом.
Мир несправедлив, увы: )
За Go поддержка такой махины, как Google, и это аргумент (линк на статью о проблемах развития D как бы говорит). Но на уровне концепций языка, по-моему, 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.
… 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.
Ну, то что сайт и pdf-ка полны заверений «Теперь всё будет хорошо», я и так вижу: ) А вот обстоятельного обзора на тему, _почему_ оные goroutines должны давать преимущество что-то не нашёл. Нет, я верю в том, что Google сумеет всё замечательно заоптимизировать — но это уже не про концепцию как таковую.
Преимущество Go — относительно простое написание конкурентных программ. Ибо CSP.
Поищите по ключевым словам Communicating Sequential Processes, Newsqueak и Limbo, что ли.
Поищите по ключевым словам Communicating Sequential Processes, Newsqueak и Limbo, что ли.
Не чувствую себя достаточно сведущим в вопрос, чтобы дискутировать по этому вопросу дальше, увы: (
Подытожу то, что хотел сказать в самом начале:
* когда я читаю о фишках D, я думаю «чёрт побери, это именно то, что мне не хватало в _языке_».
* когда я читаю о фишках Go, я думаю «это отличная штука, но это всё реализуется на уровне библиотеки для любого достаточно низкоуровневого языка» *(по ключевым словам поискал и изучил в меру своего понимания)
Поэтому мне несколько обидно, что _язык_ проигрывает _технологиям_.
Подытожу то, что хотел сказать в самом начале:
* когда я читаю о фишках D, я думаю «чёрт побери, это именно то, что мне не хватало в _языке_».
* когда я читаю о фишках Go, я думаю «это отличная штука, но это всё реализуется на уровне библиотеки для любого достаточно низкоуровневого языка» *(по ключевым словам поискал и изучил в меру своего понимания)
Поэтому мне несколько обидно, что _язык_ проигрывает _технологиям_.
>когда я читаю о фишках D, я думаю «чёрт побери, это именно то, что мне не хватало в _языке_».
Да, я тоже так думал, когда познакомился с D :)
>Поэтому мне несколько обидно, что _язык_ проигрывает _технологиям_.
Мне кажется, это проявление того самого worse is better, о котором говорил Richard Gabriel.
Да, я тоже так думал, когда познакомился с D :)
>Поэтому мне несколько обидно, что _язык_ проигрывает _технологиям_.
Мне кажется, это проявление того самого worse is better, о котором говорил Richard Gabriel.
Программы с goroutines должны легко и прозрачно масштабироваться на их железе, насколько я понимаю.
На момент придумывания Go, D уже вполне существовал. Авторов Go этот язык не устроил в первую очередь тем, что он стал представлять собой настоящую свалку всевозможных фич, что не идёт ему на пользу. Хороший язык программирования должен быть лаконичен.
«Свалка»? На данный момент моим любимым языком является C++, и все добавленные фичи D, о которых я знаю, выглядят востребованными и логичными относительно него.
А излишняя лаконичность, увы, часто выливается в нехватку мощностей и обилие костылей.
А излишняя лаконичность, увы, часто выливается в нехватку мощностей и обилие костылей.
Пример в студию!
В том же С++ лаконичность синтаксиса на уровне идеологии (и пусть в меня кинут камнем за такие слова) привела к необходимости его таки расширить странным кадавром typename. Костыль.
В, скажем, Java (поправьте если ошибаюсь), есть лаконичность системы типов вида «всё есть объект». Это красиво, но что делать, если, чёрт побери, мне _не нужен_ объект? Нехватка мощности.
В, скажем, Java (поправьте если ошибаюсь), есть лаконичность системы типов вида «всё есть объект». Это красиво, но что делать, если, чёрт побери, мне _не нужен_ объект? Нехватка мощности.
Я подумал про лаконичность модели, а не синтаксиса.
Лаконичность синтаксиса в контексте C++ как-то странно звучит… По количеству БНФ выражений в стандарте он один из рекордсменов.
Java имеет свои проблемы от желания быть «и в райкоме и в раю», Smalltalk, Ruby, Python и ещё куча языков прекрасно живут с моделью «всё объект».
Лаконичность синтаксиса в контексте C++ как-то странно звучит… По количеству БНФ выражений в стандарте он один из рекордсменов.
Java имеет свои проблемы от желания быть «и в райкоме и в раю», Smalltalk, Ruby, Python и ещё куча языков прекрасно живут с моделью «всё объект».
>На данный момент моим любимым языком является C++, и все добавленные фичи D, о которых я знаю, выглядят востребованными и логичными относительно него.
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. ©
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. ©
Если Ваш любимый язык — С++, то D действительно является его логичным развитием. Go является, на самом деле, развитием C, а не C++.
Вообще, это достаточно естественное противостояние между языками, предоставляющими максимум фич и языками, стремящимися к лаконичности. Это как перл и питон.
Как показывает пример питона, лаконичный язык вовсе не обязательно ведёт к «костылям».
Вообще, это достаточно естественное противостояние между языками, предоставляющими максимум фич и языками, стремящимися к лаконичности. Это как перл и питон.
Как показывает пример питона, лаконичный язык вовсе не обязательно ведёт к «костылям».
ещё один Cи-подобный язык
Пока что Go — это сферический конь в вакууме. Ни среды разработки, ни дебаггера, ни версии под винду, ни шаблонов, ни классов — все ООП идет лесом. Да, 20 милисекунд компиляции — это круто. Но это как в том анекдоте: «А Вы правда печатаете 800 знаков в миниту? — Да, но такая фигня получается»
Простите, а где написано что Go относится к Google?
Это тоже делают: code.google.com/p/unladen-swallow/
Увы, надежды получить эффективный аналог С++ с полноценной поддержкой лямбд, эффективным typeid в рантайме (и без мусоросборщика как в D ), пока не оправдалась.
А чем вас мусоросборщик не устраивает?
Боюсь что ответ на этот комментарий вызовет наброс на вентилятор.
Мне лично мусоросборщик не нужен. В С++ у меня нет проблем с потерянными new/delete. Особенности используемого фреймворка. Поэтому ещё один поток для сборки мусора — лишняя сущность, особенно в силу особенностей задач (промышленная автоматика) заведомо неизвестным образом увеличивающая время реакции системы.
Мне лично мусоросборщик не нужен. В С++ у меня нет проблем с потерянными new/delete. Особенности используемого фреймворка. Поэтому ещё один поток для сборки мусора — лишняя сущность, особенно в силу особенностей задач (промышленная автоматика) заведомо неизвестным образом увеличивающая время реакции системы.
А что за используемый фреймворк?
U++
Если интересно, знакомство можно начать вот с этой ссылки:
ultimatepp.org/www$uppweb$overview$en-us.html
Если интересно, знакомство можно начать вот с этой ссылки:
ultimatepp.org/www$uppweb$overview$en-us.html
> В С++ у меня нет проблем с потерянными new/delete.
Ну-ну, расскажите-ка, как такое возможно?
Ну-ну, расскажите-ка, как такое возможно?
Use smart pointers, Luke!
Но я читал, эти Smart pointers несут оверхед, ведь на каждую операцию типа передачи объекта в функцию, вызываются методы retain/release или как вы их называете. Кроме того, говорят, в многопоточном окружении надо делать блокировки на увеличение/уменьшение счетчика (хотя это не так важно имхо). Плюс сложности с weak pointers, когда объекты содержат ссылки друг на друга. А как быть с ситуациями типа замыканий, когда надо передать куда-то функцию с присоединенными к ней объектами, тут все еще сложнее!
В общем, я думаю, что эти штуки должны где-то на уровне языка поддерживаться а не писаться сверху и нести оверхед. Тогда компилятор мог бы использовать оптимизации, например предотвратить клонирование объекта и вызов retain/release при передаче его в функцию, если он больше не используется, пример:
void func () {
Object a(); // refcount = 1
someFunc(a); // создается и передается копия a, а можно было бы передать оригинал
…
// здесь освобождается a
}
В общем, я думаю, что эти штуки должны где-то на уровне языка поддерживаться а не писаться сверху и нести оверхед. Тогда компилятор мог бы использовать оптимизации, например предотвратить клонирование объекта и вызов 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."
Дело в том, что фреймворк использует свои контейнеры, которые позволяют очень быстро и эффективно работать с объектами. Если не вдаваться в подробности, в коде почти полностью отсутствуют 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."
Ну, «Everything belongs somewhere» — конечно хороший подход и способствует какому-то порядку, но есть проблема с передающимися откуда-то куда-либо объектами, типа строк например, их кто-то должен выделять, кто-то осовбождать + надо их эффективно передавать, без лишних копирований и strdup()
Очень верное замечание. Для этого существует Moveable-типы и Pick-семантика:
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
(ссылки придётся открывать вручную, они неверно парсятся)
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
(ссылки придётся открывать вручную, они неверно парсятся)
Спасибо, почитаю. Но ведь как я понял, фреймворк накладывает на программиста определенные трудно проверяемые (компилятором например) правила, и в случае их нарушения, в программе к примеру будет течь память? Кроме того, правила сильно усложняют написание программ, я например, привык в php использовать и копировать строки и объекты, не задумываясь, что там с ними происходит, о конструкторах копирования, и прочем, а тут так не получится ((
Т.е. использование фреймворка сильно уложняет и без того сложный C++ :(
Т.е. использование фреймворка сильно уложняет и без того сложный C++ :(
А тут происходит идеологическое разделение на тех, кто считает, что испльзовать что-то, не задумываясь — это ок, и тех, кто так не считает: )
Скажем так. Фреймворк вырабатывает определённый рефлекс пользования своими типами и контейнерами. Вероятность утечек памяти при этом на порядке ниже чем в классическом С++ через STL.
Что касается сложности: действительно, U++ агрессивно использует некоторые подвинутые вещи в С++ и требует достаточно высокой квалификации программиста. Т.е. фреймворк обладает выоским цензом на вхождение и достаточно крутой кривой обучения. Но взамен же вы получаете возможность писать крайне эффективные кросс-платформенные приложения без утечек памяти и некоторых прочих недостатков.
Что касается сложности: действительно, U++ агрессивно использует некоторые подвинутые вещи в С++ и требует достаточно высокой квалификации программиста. Т.е. фреймворк обладает выоским цензом на вхождение и достаточно крутой кривой обучения. Но взамен же вы получаете возможность писать крайне эффективные кросс-платформенные приложения без утечек памяти и некоторых прочих недостатков.
Я вас понял :) Просто хотелось бы язык с продвинутым и удобным синтаксисом, типа Руби (ну или хотя бы D), но компилируемый и без мерзких сборщиков мусора и многомегабайтного потребления памяти ((
То есть, в идеале, чтобы избавляться от лишних deep copy при возврате занчений из функции не использвоанием Pick, а чтобы компилятор все это прозрачно делал :)
Будем ждать, вдруг кто напишет?
То есть, в идеале, чтобы избавляться от лишних deep copy при возврате занчений из функции не использвоанием Pick, а чтобы компилятор все это прозрачно делал :)
Будем ждать, вдруг кто напишет?
>эти Smart pointers несут оверхед
в си можно выбирать какой будет оверхед(смартпоинтеров много разных), а решения встроенные в язык обеспечивают полный оверхед всегда. Ведь там решают проблемы, которых нет в большинстве случаев.
>на каждую операцию типа передачи объекта в функцию, вызываются методы retain/release
зачем так неразумно использовать умные указатели?
>someFunc(a); // создается и передается копия a, а можно было бы передать оригинал
Это си? Имелось в виду использование стэка func() в someFunc()? надеюсь уже поняли что это бред :)
в си можно выбирать какой будет оверхед(смартпоинтеров много разных), а решения встроенные в язык обеспечивают полный оверхед всегда. Ведь там решают проблемы, которых нет в большинстве случаев.
>на каждую операцию типа передачи объекта в функцию, вызываются методы retain/release
зачем так неразумно использовать умные указатели?
>someFunc(a); // создается и передается копия a, а можно было бы передать оригинал
Это си? Имелось в виду использование стэка func() в someFunc()? надеюсь уже поняли что это бред :)
>>на каждую операцию типа передачи объекта в функцию, вызываются методы retain/release
> зачем так неразумно использовать умные указатели?
Что значит, зачем?
Вот в таком коде:
SmartPointer smartpointer(...);
someFunc(smartPointer);
smartPointer передается по значению, так? Значит — создается новый объект, точнее копия, и передается в функцию в кач-ве фактического параметра. Вот и оверхед.
> зачем так неразумно использовать умные указатели?
Что значит, зачем?
Вот в таком коде:
SmartPointer smartpointer(...);
someFunc(smartPointer);
smartPointer передается по значению, так? Значит — создается новый объект, точнее копия, и передается в функцию в кач-ве фактического параметра. Вот и оверхед.
Передавайте константную ссылку, если сильно надо, делов то.
По поводу оверхеда: во всех распространенных языках с управлением памяти есть такой же или похожий оверхед, связанный с трекингом ссылок (например, в .net присваивание ссылок будет чуть дольшим, чем просто копирование адреса) — ну кроме консервативного Boёhma, наверное.
Это не значит, что smart pointer-ы чем-то хуже. Это значит, что тупо бесплатных вещей не бывает.
По поводу оверхеда: во всех распространенных языках с управлением памяти есть такой же или похожий оверхед, связанный с трекингом ссылок (например, в .net присваивание ссылок будет чуть дольшим, чем просто копирование адреса) — ну кроме консервативного Boёhma, наверное.
Это не значит, что smart pointer-ы чем-то хуже. Это значит, что тупо бесплатных вещей не бывает.
> Передавайте константную ссылку, если сильно надо, делов то.
Эээ, а как тогда будет refсount считаться и память освобождаться? Не, это ненраильный способ.
Эээ, а как тогда будет refсount считаться и память освобождаться? Не, это ненраильный способ.
Нормально он будет считаться, вы гоните имхо. Так как стек вложенной функции разрушится раньше, то и утечек не будет, все посчитается корректно.
Но внутри этой функции объект может быть скопирован, сохранен в какой нибудь массив, и прочее, т.е. его refcount изменится. А так как мы передает константную ссылку, то он по идее измениться не должен. это вообще что-то странное, не находите?
Это — странное, нахожу.
Но выше ведь обсуждали _возможные_ оверхеды. Так что в этом частном случае, если функция его никуда не передает, можно отдавать константный smart_pointer либо вообще голый pointer (smart для единообразия).
Я прокомментировал только вот эту вашу фразу: «SmartPointer передается по значению, так? Значит — создается новый объект, точнее копия, и передается в функцию в кач-ве фактического параметра».
Так что из кода, который приведен, совсем не следует, что будет оверхед.
Если передавать копию — конечно будет оверхед, но это плата за то, что вы его куда-то (смартпойнтер) собираетесь передаыть/копировать/разделять
Но выше ведь обсуждали _возможные_ оверхеды. Так что в этом частном случае, если функция его никуда не передает, можно отдавать константный smart_pointer либо вообще голый pointer (smart для единообразия).
Я прокомментировал только вот эту вашу фразу: «SmartPointer передается по значению, так? Значит — создается новый объект, точнее копия, и передается в функцию в кач-ве фактического параметра».
Так что из кода, который приведен, совсем не следует, что будет оверхед.
Если передавать копию — конечно будет оверхед, но это плата за то, что вы его куда-то (смартпойнтер) собираетесь передаыть/копировать/разделять
передаём прямую ссылку на объект с intrusive smart pointer'ом. Если захватываете где-то на стороне объект, то увеличиваете его счётчик. Оверхед минимальный.
Всё там нормально будет.
struct X {
};
std::vector< boost::shared_ptr > xs;
void foo(const boost::shared_ptr & x) {
xs.push_back(x);
}
Это будет нормально работать.
Я вот одного не понимаю. Зачем рассуждать о том, устройства чего не понятны.
struct X {
};
std::vector< boost::shared_ptr > xs;
void foo(const boost::shared_ptr & x) {
xs.push_back(x);
}
Это будет нормально работать.
Я вот одного не понимаю. Зачем рассуждать о том, устройства чего не понятны.
Сборщиков мусора для той-же явы тоже вагон и маленькая тележка. А уж придумано алгоритмов — пиши-не-хачу.
Мусоросборщик в D опционален, разве нет?
«Полноценная поддержка лямбд» и «без мусоросборщика» это какбе взаимоисключающие пункты.
Кстати, существуют реализации GC реального времени.
Кстати, существуют реализации GC реального времени.
Необязательно. В ATS есть linear closures, которые выделяются на стеке. Естественно, такой подход заработает не всегда (в частности, все, что выделено на стеке, нельзя возвращать из функции...).
Интересно, а что такое ATS? Диалект Scheme?
(Хотя, замыкания, которые нельзя вернуть из функции все-таки трудно назвать «полноценными» ;)
(Хотя, замыкания, которые нельзя вернуть из функции все-таки трудно назвать «полноценными» ;)
Да, про полноценность я погорячился. (Наверное, просто хотелось поделится сокровенным же. :))
ATS это Applied Type System, диалект Dependent ML: www.ats-lang.org
ATS это Applied Type System, диалект Dependent ML: www.ats-lang.org
А чем вам не нравится OCaml?
по талисману сразу видно, кто приложил руку к Go. уж очень он похож на Гленду с Plan9
И кто после java/c# захочет сесть на этот велосипед?
А я думал, кого мне напоминает эмблема.
Точно — это же из серии Plan 9. Знакомьтесь, Glenda:
Потому что Go — от авторов Plan 9
Точно — это же из серии Plan 9. Знакомьтесь, Glenda:
Потому что Go — от авторов Plan 9
а также от людей причастных к C и UNIX
Они и не скрывают.
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.
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.
Я думаю, Go ждёт та же огромная популярность, что и Plan9
спасибо КО
а тех, кто пишет на этом языке будут называть Goпники
для удобства восприятия тела цикла достаточно обособить его пустыми строчками. Сравните:
И кстати, число не итерабельно. :-)
for i in range(10): a = a + 1 b = a * 2
И кстати, число не итерабельно. :-)
Нич-чего не понимаю. Именно отступы и помогают вышеописанный пример. Вот с фигурными скобками и необязательными отступами могло бы быть непонятнее:
for (i = 1; i <= 15; i+c[i]){
a = a+b[15]}
b = a * 2
Народ уже домены регистрирует под это дело. Вон, .ru уже зарегили (сегодня, кстати!) Какой следующий?
Интересно когда гугл введёт собственный язык для общения. Тогда весь мир будет говорить на одном едином языке. Гугл сможет увеличить производительность, т.к. все сотрудники из разных стран будут сходу понимать друг друга.
Ну сборщик мусора добавили, что-то еще легче сделали.
Питоном он от этого не станет.
Все равно это C, у которого {{много:: ненужных;; символов_и_слов}}; и:: вообще(читать) {невозможно}.
Питоном он от этого не станет.
Все равно это C, у которого {{много:: ненужных;; символов_и_слов}}; и:: вообще(читать) {невозможно}.
И никто limbo (из inferno) не вспомнил. А ведь в go больше из limbo, чем из их общего прародителя С (например, каналы, создание переменных). Убрали только «лишнюю» пунктуацию :)
мне кажется, что это не технический спор, а чисто политические действия гугля
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Google Go = Python и C++