LINUX.ORG.RU

Андрей Александреску, The Case for D

 , александреску, ,


0

0

Перевод статьи The Case for D, выполненный сообществом сайта http://dprogramming.ru/d/

Мы, программисты, — странный народ. Достатчно взглянуть на то, как мы выбираем любимые языки и придерживаемся этих предпочтений в дальнейшем. Ожидаемая реакция программиста, заметившего на полке книжного магазинаиздание “Язык программирования XYZ” — “Даю себе ровно 30 секунд, чтобы найти в нём что-нибудь, что мне не понравится”. Изучение языка программирования требует времени и усилий, а результаты появляются не сразу. Попытка избежать этого — проявление инстинкта выживания. Ставки высоки, вложения рискованны, так что лучше уметь принимать быстрое решение “против”.

Изучение нового языка программирования может представлять интерес только в том случае, если язык удовлетворяет принципам, которые программист высоко ценит. Любое несовпадение создаёт у программиста впечатление небрежного и небезопасного или же навязчивого и нудного языка. Язык не может одновременно устраивать всех и каждого, он должен аккуратно выбирать основные координаты, позиционируя себя среди языков программирования.

>>> Перевод (pdf)

★★★★★

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

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

Ужос. Т.е. константа в с++ изменяемая? Так а чем он тогда отличается от банальной переменной?

А понял. Смысл в const вложен совершенно инопланетный относительно других языков. Подозреваю - близко к readonly в С#

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

>> По моему только Александреску в конце концов приблизился к тому чтобы соорудить из изначально бесполезных шаблонов что-то стоящее наподобие языка спецификации проектирования

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

Акробатики в его подходе меньше всего - он намечает цель где-то на горизонте и идет к ней строго по прямой, причем не нарушая правил (стандарт ANSI/ISO). Причем цели он выбирает достойные. А то что результат получается таким монструозным и по факту хрупким несмотря на строгое соответствие стандарту это уже личная заслуга Строуструпа.

Так что тут неверна изначальная задумка.

Какая задумка - параметризованные типы?

Ну да - вся затея не работает. Надо было не выпячиваться и делать нормальные макросы как в лиспе.

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

Ужос. Т.е. константа в с++ изменяемая?


в C++ есть кроме переменной еще и указатель
так вот const может по разному влиять на переменную и переменую типа указатель

1 переменная может меняться но нельзя изменить указатель
2 указатель может меняться но нельзя изменить переменную

:))

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

> Ужос. Т.е. константа в с++ изменяемая? Так а чем он тогда отличается от банальной переменной?

Её нельзя изменить, но можно в разных объектах инициализировать разными значениями в конструкторе. А после создания объекта менять нельзя.

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

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

> Александреску - акробат, который должен отправиться в адЪ вслед за Степановым.

Акробат — согласен. К его книгам в обязательном порядке должна прилагаться надпись типа «трюки в фильме выполняли каскадеры, не пытайтесь их повторить на личном автомобиле». Но в адЪ это уж слишком.

То, что этот акробат приложил руку и к D - серьезный минус в моих глазах.

х.з. скорее наоборот, там эти трюки становятся уже не трюками

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

>>> Так что тут неверна изначальная задумка.

Какая задумка - параметризованные типы?

Ну да - вся затея не работает.

«Я знал, что ты это скажешь» (с) Спорить не буду, ибо бесполезно.

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

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

Скорее, дыра... Если честно.

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

> х.з. скорее наоборот, там эти трюки становятся уже не трюками

Но станут ли они от этого «нормальным стилем» вождения. Это уже вопрос. :)

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

докури)

Я не про указатели, а про пример, что был выше. Проясни в чем разница между эти объявлениями не указателей.

static const int x1 = 1;
const static int x2 = 2;
static int const x3 = 3;
const int static x4 = 4;
int static const x5 = 5;
int const static x6 = 6;
HexGhost
()
Ответ на: комментарий от hawai

С++ скорее всего умрёт, его заместят языки из новой волны. на

ктороых можно легко и непринуждённо писать код, не заморачиваясь на

нужды языка (да, это указатели, память, синтаксиса). На сегодняшний

день на C++ приходится писать слишком много кода и помнить слишком

много деталей, что бы получить результат


плохо что многие кто не освоил C++ хаят его
есть очень много людей которые его знают и даже хорошо знают
но очень мало тех кто дествительно пишет на нём хороший код

вот те кто не освоил С++ уже присматриваються на D

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

> Скорее, дыра... Если честно.

Не дыра в том смысле, что если в языке есть ассемблерные ставки, то такие хаки можно всегда сделать.

В java для такого вида хаков можно использовать reflection. Не далее чем пару недель назад пришлось protected поле менять не в наследнике через reflection. Хотя язык этого вроде как не разрешает, но можно.

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

«плохо что многие кто не освоил C++ хаят его есть очень много людей которые его знают и даже хорошо знают но очень мало тех кто дествительно пишет на нём хороший код»

С другой стороны, поговорка «На С++ хорошую программу написать можно, но это слишком долго» тоже не на пустом месте родилась.

«даже хорошо знают» Ну вот сейчас разбираю библиотечку с CodeProject - html parser. Вроде бы и какой-то браузер чел сваял, но как: написал свой top-down малопонятный рекурсивный парсер, свою реализацию strtok... - что тоже показательно. Высокая степень велосипедостроительства :)

«очень мало тех кто дествительно пишет на нём хороший код» Ну эта фраза 100% применима и к паскальщикам, и к пистонщикам, и к руби, и ко всему-всему-всему :)

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

> С++ скорее всего умрёт, его заместят языки из новой волны. на ктороых можно легко и непринуждённо писать код, не заморачиваясь на нужды языка (да, это указатели, память, синтаксиса). На сегодняшний день на C++ приходится писать слишком много кода и помнить слишком много деталей, что бы получить результат. Пока у конкурентов много недостатков, но скоро это поправят. C останется - на его лавры пока никто не претендует.

_Никогда_ он не умрёт, слишком много кода на нём написано, до полной реализации квантового компьютера. Невозможно написать эффективную программу ни на каком языке не принимая во внимание этих деталей. Даже с gc необходимо знать что такое память как они выделяется и что она освобождается, иначе у тебя будет shit а не программа. Рано или поздно рюшечки становятся не интересны, и тогда побеждает простота и эффективность.

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

Тут Линус видимо прав, я офигел, когда реально померил скорость

плюсовых исключений. А ведь раньше не верил


все зависит от реализации
да ексепшены плохи в std::
но это минус std (abi) что они так реализованы

Линус не прав был когда отверг имплементацию ексепшинов в ядро
тем самым отказав в полном использовании С++ в ядре

многие программисты согласны в том что нет смысла тягать указатель на структуру по всем функциям
поскольку в каждом обьекте C++ этот указатель уже передаеться через ecx регистр
нет это конечно же не значит что нужно переписать все линукс ядро на С++
но полнофункциональное использования С++ в линукс ядре было бы суппер

а скорость раскрутки ексепшенов уже будет зависеть от реализации этого в ядре

в винде же работает
и достаточно быстро

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

C++ выглядит уродливо когда с ним идёт в комплекте STL и Boost
ежели их выбросить
и абстрагироваться к C++ как к стандарту - он очень хорош

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

> Рано или поздно рюшечки становятся не интересны, и тогда побеждает простота и эффективность.

Иными словами, Лисп. ;)

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

> Не дыра в том смысле, что если в языке есть ассемблерные ставки, то такие хаки можно всегда сделать.

Да. В этом смысле Вы правы. Но я о другом, на самом деле. Стоит ли так делать?

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

> в винде же работает и достаточно быстро

Видел давненько исходники ядра оффтопика. С++ там мало. Впрочем, _все_ исходники мне не были интересны. Рассматривались только отдельные части.

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

в общем-то, это недостаток Д, который его полностью инвалидирует как

замену с++


т.е. да, в Д исправлена куча косяков с++, добавлено кое-что

полезное, и сам по себе он лучше с++


язык D мне напоминает программера который хочет программить на C#/java используя C++

но полезность D для меня пока что туманна
пусть еще десяток лет поживет а там посмотрим

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

> Линус не прав был когда отверг имплементацию ексепшинов в ядро тем самым отказав в полном использовании С++ в ядре

Возможно. Вот только мы про ядро малость выше пообщались. Как Вы представляете себе реализацию отдельной части С++ (механизма исключений) в отрыве от других частей С++? Или нужно было сгондобить довесок к ядру? Но тогда это уже не моноядро получится. А микроядро. Со всеми вытекающими.

Linus, по всей видимости, просто уменьшил себе число проблем. Не более.

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

Видел давненько исходники ядра оффтопика. С++ там мало. Впрочем,

_все_ исходники мне не были интересны. Рассматривались только

отдельные части


на С++ в _оффтопике_ реализована win32k.sys - тоесть GUI
так же на C++ там весь DirectX

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

а на чистом С в _оффтопике_ реализовано остальное потому что удобней и понятней експортировать биндинг _strcmp например
чем ??_L@YGXPAXIHP6EX0@Z1@Z

да и експорируемая функция в _оффтопике_ дефакто уже стандарт
тоесть если она експортируеться она документирована и готова к использованию ее так легче запоминать в формате языка С
а вот тот же DirectX еспортирует vtbl от С++ классов называя их Interface

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

Возможно. Вот только мы про ядро малость выше пообщались. Как Вы >представляете себе реализацию отдельной части С++ (механизма >исключений) в отрыве от других частей С++? Или нужно было сгондобить


TRY/CATCH/THROW
живут и без С++
сами по себе
если они реализованы

довесок к ядру? Но тогда это уже не моноядро получится. А микроядро. >Со всеми вытекающими.


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

Linus, по всей видимости, просто уменьшил себе число проблем. Не более


Линус большинство своей жизни программировал свой процессор где никакого программирования толком нет
тем самым он себе нарушил представления о языке С
ну и темболее С++ Линус и не знал

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

Но я о другом, на самом деле. Стоит ли так делать?

Что именно? Как механизм языка - не сильно мешает. Нужно ли так писать - нет, не нужно. Много проблем - запутанность кода, конфликт с аппаратной защитой, конфликт с оптимизацией.

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

#include <cstdio>
int main(){
	const int x = 1;
	*(int*)(&x) = 3;
	printf("%d\n", x);
	printf("%d\n", *(&x));
	printf("%d\n", *(int*)(&x));
	return 0;
}
HexGhost
()
Ответ на: комментарий от tailgunner

> Александреску - акробат, который должен отправиться в адЪ вслед за Степановым. То, что этот акробат приложил руку и к D - серьезный минус в моих глазах.

В чём собственно проблема? В С++ простые «метавещи» выражаются сложным образом. Если тебе не нужна эта акробатика - использовать её никто не заставляет. То, что в С++ эти самые метавещи вообще как то выражаются - плюс, и достаточно большой. И то, что Александреску кого то научил пользоваться этой частью С++ - хорошо. Если кто то не понимает когда эта дополнительная сложность оправдана, а когда нет, это не проблема инструмента (точнее, может быть проблема, но лишь частично). STL-ем пользоваться никто не заставляет. Сам по себе он простой (я никогда не понимал идиотских имён переменных и членов класса в его реализации, из за которых код кажется обфусцированным донельзя, но это проблема реализации). Несложно написать ему замену, или использовать 1 из 10000 готовых.

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

const int x будет помещён в readonly память и попытка изменить эту ячейку бросит аппаратное исключение. Я не проверял, но уверен что так и будет. Ошибка выполнения, конечно.

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

Будет под линуксом. Что под вендой будет хз, там такие вещи вроде немножко по-другому компилируются. По стандарту неопределённое поведение.

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

Лично мне в STL нравится одна вещь, которую почему-то я больше нигде не вижу: указание сложности тех или иных алгоритмов. Ну и чем там имена обфусцированные - не знаю, вроде все довольно просто. Хотя диапазоны в D и совершенно убойное выражение sort(chain(a, b, c)) меня поразили напрочь - точно погляжу поближе, а там и перейду, может быть... Благо я сам выбираю, на чем писать проекты

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

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

http://ru.wikipedia.org/wiki/Не_читал,_но_осуждаю!

У меня отработало на fedora core 6 (компилил как g++ так и gcc). И на vista x64 (visual studio 2008). Исключений не было ни в одном из трёх вариантов, а вывод программ разный.

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

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

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

> В чём собственно проблема? В С++ простые «метавещи» выражаются сложным образом. Если тебе не нужна эта акробатика - использовать её никто не заставляет.

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

Несложно написать ему замену

Ты запредельно крут.

или использовать 1 из 10000 готовых.

Можно, конечно.

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

>Рано или поздно рюшечки становятся не интересны, и тогда побеждает простота и эффективность.

Я бы и рад с тобой согласиться (не касательно С++, а простоты и эффективности), но пока всё говорит, что "Рано или поздно рюшечки становятся не интересны, и тогда побеждает простота и эффективность _написания программ_!" И конца этому не видно. Да я, если честно, и не уверен, что этот путь не есть правильный

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

Отлично, меняем cstdio на stdio.h Правим расширение файла и компилим gcc. У меня на g++ и gcc получился разный результат ;-)

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

Отлично, меняем cstdio на stdio.h Правим расширение файла и компилим gcc. У меня на g++ и gcc получился разный результат ;-)

Мда, занятно...

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

> "... и тогда побеждает простота и эффективность _написания программ_!"

Да ну, сделай wc -l программ в любом дистрибутиве и потом расскажи что побеждает.

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

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

Ну undefined behavior ведь, какая разница что получилось если так ( *(int*)(&x) и (*(int*)(&x))) писать нельзя?

Кто сказал что компилятор обязан положить константы в .data?

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

> Ну undefined behavior ведь

Да, поэтому я и привёл это в пример, почему так делать не надо. Если не везёт, то плохие конструкции могут даже скомпилироваться и исполниться, получится замечательный источник глюков в программе, зависящий от системы, компилятора и положения звёзд.

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

> С99 - комплексной математики быстрее не бывает.

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

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

>STL. Искренне надеюсь, что за это Степанов оправится в адЪ.

Гораздо раньше там окажутся авторы жабы, php и питона и адЪ засвопится на неопределённо долгий срок.

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

>Да ну, сделай wc -l программ в любом дистрибутиве и потом расскажи что побеждает.

Самому не стыдно за такую "аргументацию"? Оффтопик побеждает "стопудова" (при несколько другом запросе).

Хоть бы на вакансии какие глянул...

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

> вот те кто не освоил С++ уже присматриваються на D

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

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

>Скорее, дыра... Если честно.

Вирт, залогиньтесь

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