LINUX.ORG.RU

Книга «Programming in D» доступна в бумажном варианте

 


0

2

Книга «Programming in D» доступна в бумажном варианте!

Популярный бесплатный онлайн-учебник теперь можно заказать в печатном виде за $28.50.

Книга значительно обновлена по сравнению с онлайн-версией, датированной 2014-ым годом. Впрочем, онлайн-версия также находится в процессе обновления и останется бесплатной. Самые нетерпеливые могут заглянуть по ссылке http://ddili.org/deleteme.epub, остальные могут подождать официального релиза, который состоится в ближайшее время. Автор книги, турецкий программист Ali Cehreli, держит свое слово — книга всегда будет доступна бесплатно, поэтому покупка бумажного варианта — чистая благотворительность и хороший способ сказать «спасибо» автору.

От себя добавлю, что книга стоящая и хорошо подходит для знакомства с D как с первым языком, не такая хардкорная как TDPL («The D Programming Language») от великого и ужасного Александреску.

>>> Подробности



Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 5)

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

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

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

--- И что? Как это мешает «стандартному» коду быть --- переносим между платформами?

--- Тем, что гольный стандартный код нежизнеспособен --- без ASM-вставок. Другое дело, что на разных архитектурах --- может не быть регистров cr0,cr3 или вообще понятия «системный вызов».

Xintrea, извините, у вас легкая степень помешательства? как код может быть нежизнеспособен при переносе без ASM-вставок? какие еще ASM-вставки? разные платформы по определению имеют разные процессоры, разные процессоры по определению имеют разные ассемблеры. причем тут переносимость и ваши ASM-вставки, которые от платформы к платформе будет бесполезны и идиотичны? код на си предполагает переносимость, например, в контексте POSIX-совместимых систем, и обладает типами, которые позволяют это сделать. причем тут эти ASM-вставки?

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

Сейчас без языка нельзя. Пропадёшь сразу, или из тебя шапку сделают, или воротник, или просто коврик для ног.

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

дык вы чего тут делаете, то?

указатель на 2 множите что-ли?

cawa
()

В предчувствии жирного юмора нажал на кнопку «показать удаленные», и был жестоко разочарован: ни одного сообщения там нет. Коллеги, да что же это такое творится-то?! :(

Теперь по теме: надеюсь, что книга на напечатана на мягкой бумаге, и покупателям не придётся долго мять страницы перед использованием?

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

D не так маниакально безопасен, как Rust, например, поэтому вместо перехода на D можно продолжать использовать C++

Поправил. Можешь не благодарить.

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 2)
Ответ на: комментарий от matumba

Ди - это как раз тот «преемник», которого давно все ждут.

Ждём. С лопатами.

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

Ди - это как раз тот «преемник», которого давно все ждут.

Он с 2000-го года примерно живет и до сих пор «ждут»?

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

как код может быть нежизнеспособен при переносе без ASM-вставок?

Вот так, нежизнеспособен.

какие еще ASM-вставки? разные платформы по определению имеют разные процессоры, разные процессоры по определению имеют разные ассемблеры. причем тут переносимость и ваши ASM-вставки, которые от платформы к платформе будет бесполезны и идиотичны? код на си предполагает переносимость, например, в контексте POSIX-совместимых систем, и обладает типами, которые позволяют это сделать. причем тут эти ASM-вставки?

При том, что помимо POSIX есть еще и железо. В треде речь как раз и идет о том, что за каким-то хреном язык C пихают как низкоуровневый язык для разработок под платформы. А он для этого и не предназначен. Поэтому и получается, что в язык через библиотеки проникают жуткие костыли в виде типов с платформонезависимыми фиксированными размерами данных. И постоянно лезут проблемы разрядности платформ, которых быть впринципе не должно.

Ты рассказываешь про переносимость в контексте POSIX, так этой переносимости по факту нет, попробуй запустить C-шный код, писаный под 32 бита на платформе 16 бит. А нет совместимости именно из-за аппаратных различий.

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

В предчувствии жирного юмора нажал на кнопку «показать удаленные», и был жестоко разочарован

И, судя по постам, срочно решили восполнить этот пробел.

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

Pure C - это достаточно компактный язык


ORLY? Что же стандарт тогда 600 страниц занимает?


Мелочи жизни по сравнению с крестами.

Давай скатимся в точные числа:
* Си ( isoiec9899.pdf ) — 550 станиц
* С++ ( isoiec14882.pdf ) — 739 страниц

Ты действительно настаиваешь, на том, что 550 страниц — это «компактно» и вообще «мелочи»?

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

У меня немного другая информация

http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4527.pdf

1367 страниц

+ о чем мы спорим? О том, компактен ли C, или о том, целесообразна ли совместимость с ним на уровне ABI? Второе у меня сомнений не вызывает, первое - на ваш вкус, некомпактен так некомпактен.

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

+ о чем мы спорим? О том, компактен ли C

У меня возражения вызвала вот эта твоя фраза: «Pure C - это достаточно компактный язык».

целесообразна ли совместимость с ним на уровне ABI?

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

Если же си-шный хидер напрямую инклудится в д-шный исходник, то ... речь идёт о совместимости не только на уровне abi, так?

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

Да, так. Я могу написать

 extern (C) int strcmp(char* string1, char* string2);

А потом

import std.string;
int myDfunction(char[] s)
{
    return strcmp(std.string.toStringz(s), "foo");
}
tired_eyes
() автор топика
Ответ на: комментарий от tired_eyes

Ну и что толку тогда на уровне языка от совместимого ABI? Было бы гораздо логичнее задачу корректного бинарного вызова си-шного (или крестового, или какого еще угодно) кода не делегировать биндингам, а не тащить в сам язык.

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 2)
Ответ на: комментарий от tired_eyes

+ возможность использовать в «обратную сторону» D-код из С

tired_eyes
() автор топика
Ответ на: комментарий от Manhunt

Мне кажется, что эти вещи не исключают друг друга.

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

Возможность бесшовного использования С-шной стандартной либы

Спорный design goal. Си-шная стандартная либа довольно убога.

тривиальность написания биндингов

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

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

библиотеками примитивов должно обеспечиваться

Насколько я знаю, обеспечивается для других языков (в частности, Python). Но это сложнее все же. Сейчас на D много биндингов к С-либам, и не в последнюю очередь благодаря легкости их написания. Мне кажется, овчинка все же стоила выделки. + когда это решение принималось, D был очень молодой язык, и это позволило сразу получить некоторое количество «батареек» минимальными усилиями.

tired_eyes
() автор топика
Ответ на: комментарий от Xintrea

Ты рассказываешь про переносимость в контексте POSIX, так этой переносимости по факту нет, попробуй запустить C-шный код, писаный под 32 бита на платформе 16 бит. А нет совместимости именно из-за аппаратных различий.

Это зависит от кода, а не от языка. Гляньте на код NetBSD например.

Не совсем понятно, почему вы считаете типы с фиксированным размером костылями. Думаете, что если сделать размер основных типов зависимым от платформы, то это решит проблемы переносимости? Уверяю вас, проблемы только умножатся.

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

Привет! Я сходу не вспомню. Могу и ошибаться за давностью лет, но у меня неприятный осадок от русского перевода TDPL.

tired_eyes
() автор топика
Ответ на: комментарий от matumba

Хотя Ди - это как раз тот «преемник», которого давно все ждут.

Что-то слабо ждут, судя по всему.

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

Давай скатимся в точные числа:
* Си ( isoiec9899.pdf ) — 550 станиц
* С++ ( isoiec14882.pdf ) — 739 страниц
Ты действительно настаиваешь, на том, что 550 страниц — это «компактно» и вообще «мелочи»?

Ты стандарты-то открой, школьник. Плюсовый включает в себя сишный за малым исключнием.

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

Мелочи жизни по сравнению с крестами.

Ну ты и лалка ))) Выпиши все что есть в D в стандарт, и получишь текста на порядок больше. Если конечно все будет описано так же детально как в С и С++.

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

Я вообще-то говорил о стандарте C в сравнении с С++

Так ты и тут лалка, выше уже написали почему.

при чем тут сообще стандарт D?

Не причем, конечно, его же нет и не будет.

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

Аноним как-то особенно сильно тупит этим чудным августовским вечером...

tired_eyes
() автор топика
Ответ на: комментарий от Manhunt

Зачем ты сравниваешь сумму и слагаемое? Ты норкоман? У меня нет других рабочих гипотез.

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

Не совсем понятно, почему вы считаете типы с фиксированным размером костылями.

Потому что в C мы имеем взаимоисключающие параграфы. С одной стороны нам говорят - вы должны писать программы независимо от особенностей платформы. С другой стороны говорят - вот вам целочислительный тип int, но помните, что на разных платформах у него разный размер!


Думаете, что если сделать размер основных типов зависимым от платформы, то это решит проблемы переносимости?

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

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

Потому что в C мы имеем взаимоисключающие параграфы. С одной стороны нам говорят - вы должны писать программы независимо от особенностей платформы. С другой стороны говорят - вот вам целочислительный тип int, но помните, что на разных платформах у него разный размер!

Не слишком ли назойливо будет предложить... D, где int един для всех платформ?

tired_eyes
() автор топика

Между тем, пока суть да дело, релиз состоялся и финальную версию книги уже можно скачать - http://ddili.org/ders/d.en/

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