Comments 34
Допустимо ли при публикации статьи указывать в сноске к ней, что она подоготвлена с помощью сервиса автоматического перевода?

P.S. Примерно в такой же ситуации, мою статью модераторы убрали с сайта, указав, что недопустимо пользоваться автоматическими переводчиками при публикации статьи на ресурсе, согласно правилам сервиса.
кстати — да
(это не автоматический перевод, если кто не заметил, и в то же время этот переводчик с элементами ИИ весьма помогает)


он, наверное, думает — если уж вручную подредактировал текст, то это не автоперевод, это, наверное, какой-то «полуавтоматический» получается
Замечания по качеству перевода — прошу в личку. Я пока не понял, как для меня лучше — с помощью дипла или со словарем.

Жена работает в крупном международном агенстве переводов, там переводятся все самые топовые компании. И весь перевод делается из машинного с последующей правкой. Даже если они заявляют обратное.

Не совсем понимаю почему D ругают за наличие в языке GC? Нет полного контроля за памятью?
Скорее по инерции тяжелого взросления GC на примере Явы.

В D можно использовать динамическую память и без GC (можно как в C руками, а можно как в C++ с RAII), а можно выделять участки программы в которых не будет GC-выделения памяти с помощью атрибута @ nogc. Есть целая серия статей тут.
Потому что GC в D медленный. Причина в том что в D не стали вводить write barrier, аргументируя это тем что это приведёт к снижению производительности, которое непозволительно для системного языка программирования. А без write barrier нельзя сделать сборщик мусора с поколениями. Поэтому в D каждая сборка мусора — это полная сборка мусора.
А если GC отключить, то тогда нельзя использовать некоторые конструкции языка типа ренджей, лямбд по-моему тоже, и стандартной библиотекой тоже нельзя было пользоваться в этом случае, так как она использовала такие конструкции (возможно её уже отвязали от GC).
А есть тесты сравнения быстродействия GC в разных языках? Хотя, конечно это сложно, ведь нагрузка на хип сильно зависит от языка.

Какая то работа над новым GC ведется, но я не разбирался в деталях, см презентацию со скоростными характеристиками с DConf 2019

Да, программу с полным отключением GC в D надо планировать писать совсем по-другому — практически без Фобоса и без исключений — это очень тяжело. Но вот вариант совмещения (только критичная часть или тред без GC) выглядит привлекательным для лентяев )
Я так понял что они работают над precise GC, чтобы точно отличать при сборке мусора ссылку от набора битов, но сделать сборку мусора с поколениями это не поможет. И параллельную сборку мусора в другом потоке они тоже сделать не смогут по причине отсутствия write barrier. Только stop the world и полная сборка.
Про тесты не знаю, но я так понимаю что сборщики мусора в C# и Java достаточно хороши

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

Стандартный синтаксис (операция конкатенации ~) требует, но строки это просто массивы и с ними можно работать как и с другими массивами. Это менее удобно и наглядно, но всё же возможно.

D себя позиционирует (или позиционировал) как улучшенный C++. При этом, C++ разработчики используют C++ потому, что он позволяет держать память под контролем. Позволяет «не платить за то, что не используешь». Да, GC в D отключаемый, но отключив его мы теряем возможность использовать классы (пока, динамический полиморфизм), а так же динамические и ассоциативные массивы. Конечно существуют библиотеки контейнеров, не использующих GC, но тут уже встает вопрос — зачем все это, если в C++ мы уже имеем тоже самое? При этом в C++ отсутствует проблема interop'а с C++ кодом по определению.

У D помимо GC ещё есть много разных фишек. Метапрограммирование читабельное и мощное, модули, пакетный менеджер, работа с массивами и т.д. Наконец синтаксис более приятный.

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

Я думаю что людям не нужен хороший язык программирования.
Людям нужен язык способный быстро и просто решать насущные задачи.
Важны не общие задачи программирования, а быстрое решение задач пользователей, за которые они готовы платить.
Взгляните на php: язык — жуть такой же кривой как javascript, но из коробки и работает с базами данных, изображениями, архивами и еще много с чем. И ресурсов не много требует.
Например нужен не контроль над памятью или отслеживание владения, а упаковка файлов в архив или распаковка видео, работа с векторными форматами, вывод на печать или pdf… Да даже с тем же интерфейсом пользователя пока полная шляпа.
Плюс язык должен обеспечивать поддержание контроля при росте кодовой базы или придётся постоянно и пристально за этим следить самим. Иначе бардак, затык и тепловая смерть.

Во-первых, не стоит путать прикладное ПО и системное. Разные цели и разные средства.


Во-вторых, условный С++ или его условный убийца, нужны, в скажем, в 3-5% задач. Но решить их эффективно в итог можно только на нём, а уже потом поверх городить все остальное. Не стоит забывать, что рантайм к некоторым из прикладных языков написан на Си или С++.


Так что никуда от этого не деться) Даже ассемблер жив до сих пор, просто теперь на нем выполняется 0,001% задач.


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

Ну 3-5% это очень интересная оценка. Я бы предложил заглянуть, скажем в «установку и удаление программ» и посчитать процент там =)
Я думаю что людям не нужен хороший язык программирования.
Людям нужен язык способный быстро и просто решать насущные задачи.

Хороший язык это тот, который помогает быстро и просто решать насущные задачи.


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

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

Хотя бы свойства (properties) сделали бы для сокращенных операций:)
module d_properties;
import std.stdio;

struct Foo {
	int z;
	@property bar() 
	{ 
		writeln("getter");
		return z; 
	}
	@property bar(int x) 
	{ 
		writeln("setter");
		z = x;
	}
}

int main()
{
	Foo foo;
	int x = foo.bar;        // ok
	foo.bar = 10;           // ok
	foo.bar = foo.bar + 20; // ok
	foo.bar += 20;          // error: `foo.bar()` is not an lvalue and cannot be modified

	getchar();
	return 0;
}


А вообще впечатление интересное. Я уже писал здесь что изучаю компилятор с целью создания на базе Ди своего языка программирования. Даже пришлось для этой цели написать систему разметки кода маркерными комментариями.
Код, скажем так, весьма специфический. Глядя на исходники компилятора, лучше всего понимаешь, что сам синтаксис языка нуждается в серьезном редизайне. Причем переписывание авторами исходников с С++ на D лишь причесало некоторые «формальные» стороны, а по сути осталось все то же самое. Backend так вообще родом откуда-то из древности, сейчас так даже на Си не пишут.
Лично меня до сих пор от __property корежит. Когда D/D2 вышел — он был красивым, чистым языком, в который потом натащили со свалки отовсюду атрибуты, трейты итд и этот процесс продолжается…
Да, производит впечатление некоторой бессистемности. Как будто сначала продумывали язык, а в какой-то момент просто стали добавлять возможности «абы как». Хотя все это и хорошие возможности, но вот не хватает продуманности в мелочах.
А как позиционируется D — как убийца С++? Тогда в чем его киллер-фича по отношению именно к плюсам? А тогда при чем здесь мобильная разработка? Не слишком ли широко берут его создатели?
А как позиционируется D — как убийца С++?

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


Тогда в чем его киллер-фича по отношению именно к плюсам?
Вы сами задали вопрос и, тут же, сами же и начали критиковать язык за свой же вопрос?
Я задал вопрос, ответ на который всем известен. И критикую я именно ответ.
А вот с этим я как раз согласен.
Не убийца, но скорее преемник. Киллер-фичи — безопасность по умолчанию и удобное метапрограммирование, вылившееся в кардинально другую стандартную библиотеку.

Язык задумывался как системный универсальный — потому охват всех платформ — важная цель.

Еще я переводил сравнение D/Rust/Go от Александреску.

Я как закоренелый сиплюсплюсник уважаю Александреску — в какой-то мере. Но смею напомнить что выражение "укушенный Александреску" появилось весьма не зря. Так что любое сравнение от него я бы "take with a grain of salt". Году эдак в 2017-м он на своей презентации натурально заявлял что концепты в С++ это плохо потому что помешают ему кодить так, как он хочет.

Слепо доверять чужому мнению конечно не стоит. Я например, сначала прочитал учебники по D/Rust/Go/Python итд

Кстати, concepts и ranges, которые появятся в С++20, давным давно есть в D. Оттуда Комитет заимствовал идею или нет, уж не знаю.

Часто пишу на D и C++ и как C++ разработчик вижу проблему D в неправильном позиционировании.
Слоган D: "write fast, read fast, run fast" и это в целом правда. На D действительно можно быстро писать читаемый код, который при этом будет относительно быстро исполняться. Есть режим "интерпретатора" для быстрой отладки и прототипирования.
Язык очень удобен, но ни как замена C++, а как замена Python!
Современный С++ самодостаточен и хорош для тех кто его знает. Пытаясь стать заменой C++ D плывёт против течения.
Высокая производительность C++ обусловлена:


  1. Возможностью полностью контролировать поток выполнения как на высоком так и на низком уровне
  2. Возможностью фронтенда компилятора выполнять оптимизации, недоступные в более безопасных языках. Все эти вещи, которые помечены в стандарте как UB дают компилятору возможность для оптимизаций.
    У D тоже получается собрать весьма эффективный код с ldc2, но оптимизаций бэкенда недостаточно. И он никогда не будет столь же быстр как C++. Даже без учёта GC.

А вот использовать D там, где используют, например Python, действительно круто.
У D достаточно много библиотек (хотя многие и весьма сырые). У D прогрессивная сложность. На нём легко начать писать с минимальной подготовкой. Код получается компактный и читаемый. Потрясающая шаблонная магия позволяет делать красивые библиотеки, которыми легко пользоваться. Встроенные юниттесты. Типобезопасность. Бинарь без зависимостей на выходе. И много много чего ещё.


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

У D прогрессивная сложность
ИМХО это как раз плохо — появляются разные стили языка. Возможно именно поэтому не взлетела Scala. Идеальная кривая для любого промышленного ЯП — невысокая ступенька _|¯
У D тоже получается собрать весьма эффективный код с ldc2, но оптимизаций бэкенда недостаточно. И он никогда не будет столь же быстр как C++.
Я бы уточнил тут немного, что потери тут на оптимизации составят единицы процентов. Но только дело не столько в оптимизаторе, а и в спорных технических решениях — классы ссылочные, строки иммутабельные, что тянет постоянную нагрузку на хип.
А вот когда сравниваем с питоном (и пхп), то получаем типичную выгоду в вычислениях 50раз, что есть 5000%… Хотя когда в том же питоне либы сишные, то потери этим нивелируются (пока не придется свои переписывать)

Так что стоит делать оговорки, в каких случаях оптимизатор «плохой» и насколько.
Only those users with full accounts are able to leave comments. Log in, please.