| |
| |
| 3.26, Crazy Alex (ok), 10:47, 22/06/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Давно не следил, но стандартную либу в этом плане правили. мроблема с том, что GC обеспечивает непоторые довольно важные плюшки, вроде бесплатных слайсов массивов. Но на этот счёт были варианты какие-то.
| | |
| |
| 4.67, 11111 (?), 12:32, 22/06/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> GC обеспечивает непоторые довольно важные плюшки, вроде бесплатных слайсов массивов.
Но зачем, если есть языки с бесплатными слайсами массивов без GC?
| | |
| |
| |
| |
| 7.76, Crazy Alex (ok), 15:02, 22/06/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Не оно ни разу. Растовская borrow semantics сильно ограничивает использование слайсов. Сделать десяток (возможно перекрывающихся, возможно мутабельных) слайсов и сохранить их в разных объектах с неопределённым временем жизни rust не даст. То есть заставит копировать массив там, где этого можно избежать.
| | |
|
|
|
|
| 3.116, menangen (?), 10:20, 28/06/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
А нахрена его отключать, пиши сразу на сишке. D и хорош тем, что это по сути "компилируемая жава".
| | |
| |
| 4.117, Andrey Mitrofanov (?), 10:54, 28/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
> А нахрена его отключать, пиши сразу на сишке. D и хорош тем,
> что это по сути "компилируемая жава".
[Саммоним в тред Главного Эксперта Опенета по Джавве, iZEN-а.] iZEN, вы-хо-ди!
| | |
|
|
|
| 1.4, Alex (??), 23:57, 21/06/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Этот ваш D умеет инклюдить сишные хидеры и использовать оттуда функции и структуры?
| | |
| |
| 2.5, nc (ok), 00:02, 22/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
 Вроде бы умеет, но только сишные (без С++ шаблонов).
| | |
| |
| 3.12, marco (??), 03:33, 22/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Может использовать сишные и плюснутые библиотеки, как раз переписав хидеры. Для гиков можно использовать в коде ассемблерные вставки.
Программы компилируются очень быстро, да и по быстродействию не проигрывают сишным. Но исполняемые файлы получаются увесистые, так как тянут сборщик мусора.
| | |
| |
| |
| 5.80, Mihail Zenkov (ok), 15:40, 22/06/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
 Мне очень нравится D, но размер исполняемых файлов явно его слабая сторона. Shared libraries не спасает: размер поставки (bin+phobos.so) будет еще больше, чем для статики. Потребление памяти для простых приложений в любом случае очень сильно завышено (в сравнении с C).
ИМХО основная проблема, что по-прежнему линкер не может выкинуть основную массу мертвого кода. Где-то было обсуждение этой проблемы, но сходу ссылку не найду.
Есть еще страница (http://digger.k3.1azy.net/trend/), на которой отслеживалась тенденция размера исполнимых файлов в зависимости от версии, но что-то у меня она ошибку выдавать стала.
| | |
| |
| |
| 7.87, Mihail Zenkov (ok), 20:08, 22/06/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Минимальный пример:
D:
import std.stdio : writeln;
import core.sys.posix.unistd : usleep;
void main() {
writeln("test");
usleep(10000000);
}
C:
#include <stdio.h>
#include <unistd.h>
void main() {
printf("test");
usleep(10000000);
}
Размер бинарника (после strip): C - 5.4K, D - 312.6K.
Потребление памяти:
Private + Shared = RAM used Program
412.0 KiB + 147.5 KiB = 559.5 KiB test_d
68.0 KiB + 68.0 KiB = 136.0 KiB test_c
Для больших программ разница будет несущественна. А вот когда пишешь небольшие системные утилиты - как-то жирновато.
| | |
| |
| 8.91, Аноним (-), 22:34, 22/06/2017 [^] [^^] [^^^] [ответить] | +1 +/– | Нет, я всё понимаю когда люди изнывают, что нужно ради одной софтины тащить пол ... текст свёрнут, показать | | |
|
|
|
|
| 4.104, glebiao (ok), 13:24, 24/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> быстродействию не проигрывают сишным. Но исполняемые файлы получаются увесистые, так как
> тянут сборщик мусора.
Дело не в сборщике мусора, там тянется много несколько неожиданных вещей,
типа рантаймовой поддержки интроспекции и т.п. имхо, с этим можно мириться: скорость И простота разработки + скорость исполнения, перевешивают недостаток толстоватых бинарников.
При динамической линковке, размер бинарника вовсе не получается катастрофическим.
| | |
|
|
| 2.6, Crazy Alex (ok), 00:31, 22/06/2017 [^] [^^] [^^^] [ответить]
| +7 +/– | |
Нет, так как сишные макросы не умеет (и правильно), да и система типов не совпадает. Для простых случаев есть тулза для трансформации, но правильный вариант - сделать нормальный модуль с вменяемым API. Собственно, основная идея D - "C++ done right", в первую очередь - без сишного легаси.
А вот сишные функции использовать, разумеется, может - при условии, что они соответствующим образом объявлены.
| | |
| |
| 3.9, Alex (??), 02:40, 22/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
"Сделать нормальный модуль с вменяемым API" - для чего? POSIX API? Или kernel-to-userspace API? Язык позиционирует себя как язык системного программирования, но мне надо воспроизвести половину системных инклюдников чтобы открыть банальный raw-сокет?
| | |
| |
| 4.25, Crazy Alex (ok), 10:42, 22/06/2017 [^] [^^] [^^^] [ответить]
| +/– | |
транслированные хидеры libc и так в комплекте. Но как раз сокет - хороший пример того, что лучше завернуть в класс, как минимум - чтобы иметь его закрытие в деструкторе. Так и сделано.
Не беспокойтесь, там довольно много "батареек включено". http://dlang.org/phobos/index.html в помощь, если интересно.
| | |
|
|
| 2.60, Zloy (?), 11:42, 22/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Есть утилиты-трансляторы заголовочных файлов в дишные модули. Так дофига биндингов к сишным либам наделано.
| | |
| |
| 3.66, Crazy Alex (ok), 12:31, 22/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Лучше всё же написать, что примерно каждый первый надо руками дочищать, так как в них макрос на макросе обычно, зависящие от того, Что определено во включающем файле. Да и нюансы с типами строк и подобным тоже автоматом не переведёшь. Но да, основную массу работы делает, да.
| | |
|
|
| 1.11, Спайк (?), 03:19, 22/06/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
для полного фарша в GCC ещё Limbo добавить и будет совсем конанично. и да, ржавые напряглись! :)
| | |
| |
| |
| |
| 4.71, Andrey Mitrofanov (?), 13:37, 22/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> гццуст
GC-crust же. //~джи си краст[CODE][jargon]:
GC
/G.C/
[from LISP terminology; Garbage Collect]
[...8<...]
[mueller7]:
crust
[krʌst]
1. _n.
1) корка (хлеба); _перен. средства к существованию; to earn one's crust
[...8<...][/CODE]
| | |
|
|
| 2.15, nc (ok), 07:45, 22/06/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
Многие вещи в Go взяты из Limbo. А Go сейчас - последний язык в этой цепочке (Newsqueak - Alef - Limbo - Go). Так что в каком-то смысле уже есть.
| | |
|
| 1.17, Нанобот (ok), 08:50, 22/06/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –7 +/– |
 >Процесс включения поддержки языка D в GCC начался ещё в 2011 году, но затянулся из-за необходимости приведения кода к соответствию требованиям GCC
GNU-бюрократия затормозила прогресс на шесть лет
| | |
| |
| 2.18, Andrey Mitrofanov (?), 09:20, 22/06/2017 [^] [^^] [^^^] [ответить]
| –8 +/– |
>>Процесс включения поддержки языка D в GCC начался ещё в 2011 году, но затянулся из-за необходимости приведения кода к соответствию требованиям GCC
> GNU-бюрократия затормозила прогресс на шесть лет
gcj выкинули наконец. патчи free pascal только для gcc 4.3. Камрады _борются_ !
| | |
| 2.64, Crazy Alex (ok), 12:27, 22/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Там основной была синхронизация разработки с DMD. GDC/LDC долго сильно отставали.
| | |
| |
| 3.77, J.L. (?), 15:18, 22/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
 > Там основной была синхронизация разработки с DMD. GDC/LDC долго сильно отставали.
а сейчас GDC/LDC по поддержке фич (и качеству генерируемого кода ?) на сравнимом уровне с DMD ?
LDC или GDC лучше брать при ознакомлении с D в каком-нить своём простеньком проекте ?
| | |
| |
| 4.84, Crazy Alex (ok), 16:55, 22/06/2017 [^] [^^] [^^^] [ответить]
| +4 +/– |
Для ознакомления на простеньком проекте - вообще всё равно какой из них брать, они давным-давно практически вровень. DMD чуть впереди, но совсем чуть. По генерируемому коду LDC был получше, насколько я помню, но оно от задачи зависит, так что если всерьёз надо выжать всё, что можно - лучше мерять.
| | |
| 4.92, Аноним (-), 22:38, 22/06/2017 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Если нужны все самые свежие фичи сиюминутно закомиченные в мастер ветку — dmd. Если нужен компилятор с нормальным оптимизатором и готовы недельку другую подождать свежих фич — ldc.
gdc долго заброшенный стоял, и только сейчас резко начал обновлятся, стоит подождать прежде чем его использовать, кроме кpacноглaзия это ничем хорошим не грозит.
| | |
| 4.101, glebiao (ok), 13:17, 24/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
dmd генерит не самый оптимальный код.
ldc значительно лучше но до последнего времени в предкомпилированной поставке
не было динамической версии стандартной библиотеки, так что компиляция была
только в статику.
последний gdc, похоже, делает хороший код, но багзилла полна.
по скорости компиляции dmd быстрее ldc быстрее gdc.
| | |
| |
| 5.109, Crazy Alex (ok), 15:16, 26/06/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Добавьте, что по самому качеству кода компилятора dmd первый - в нём, как правило, в первом исправляются баги и он по-прежнему является эталоном.
Но за исключением каких-то совсем уж серьёзных проектов всё это не прицнипиально совершенно, можно любой из трёх брать.
| | |
|
|
|
|
| 1.24, Аноним (-), 10:40, 22/06/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –5 +/– |
Поскольку FSF не любит C++, то, может, полюбит D. Идея для Gtk'шников - переписать Gtk на D и убить двух зайцев. 1) Помочь взлететь языку, использовав в популярном тулките. 2) Поправить пошатнувшииеся позиции Gtk, переписав его на настоящем ОО ЯП.
| | |
| |
| 2.62, Zloy (?), 11:45, 22/06/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
Идея отличная. Но на дишечке итак делается dlangui, проще тогда уже его доводить до конкурентноспособного состояния.
| | |
| |
| 3.79, Pinkie (?), 15:31, 22/06/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
dlangui делается одним человеком, это любительский проект.
Gtk же штука покрупнее. Плюс, насколько я понял - в dlangui парсится строка текста как разметка, а очень хотелось бы описание интерфейса компайлтаймовым языком, как в Vibe.d diet-шаблоны описываются.
| | |
| |
| 4.82, Crazy Alex (ok), 15:42, 22/06/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Я бы сказал, что Gtk - штука сильно покрупнее, чем вообще надо для GUI.
А что пишется одним человеком - ну много чего так начинается, можно линуксовое ядро вспомнить ;-) Впрочем, идея D как гнушного базового языка в любом случае сомнительна. У них большинство архитектурных решений как-то странно принимается, у какой-нибудь Scheme и то больше шансов будет.
P.S. Судя по гитхабу их там всё же четверо. А вещь на вид неплохая, пригодится.
| | |
|
|
|
| 1.75, анонимбр (?), 14:06, 22/06/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
(Как-то натыкался на такой проект) D программы быстро собираются поэтому вполне можно писать и скрипты на нем.
| | |
| |
| |
| 3.81, Crazy Alex (ok), 15:40, 22/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Ты с джавой перепутал. ООП здесь не страшнее, чем в том же питоне. Можно и в чисто процедурном стиле свой код писать.
Типизация - auto в помощь. Переменные объявлять придётся, но для скрипта больше, чем в пять строк, это только плюс. А если больше 50 строк - типизация резко становится полезной.
| | |
| |
| 4.86, Аноним (-), 19:12, 22/06/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
В скрипте не нужно ооп, типизация и python. Либо вы не совсем понимаете значение термина "скрипт".
| | |
| |
| 5.93, Crazy Alex (ok), 02:48, 23/06/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
В скрипте на пять строк - не нужно (хотя не мешают). В чём нибудь вроде скрипта бэкапа или для сборки строк на 400 - уже помогают. В скриптах вроде тех, которыми я в своё время музыку с торрентов в стандартный для себя формат преобразовывал (а там и парсинг метаданных, и генерация каталога и прочее) - уже очень к месту. Там, правда, перл был. Классы в скриптах, конечно, никто не пишет, а вот то, что библиотечные функции удобно сгруппированы по модулям/классам - гуд.
| | |
|
|
| 3.102, glebiao (ok), 13:20, 24/06/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Скрипты с типизацией и с ООП? Да ну к черту вас.
на D есть такой замечательный проект, поддержка программирования в скрипотовом стиле.
легко писать "скрипты" на D практически в питоновском ключе.
так что, вполне.
| | |
| |
| 4.105, Аноним (-), 21:15, 24/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
Python - это сильно "не первый сорт", поэтому очень зря ориентиро на него.
| | |
| |
| 5.106, glebiao (ok), 22:11, 24/06/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Python - это сильно "не первый сорт", поэтому очень зря ориентиро на него.
И что первый? PowerShell?
| | |
| 5.112, Аноним (-), 22:22, 26/06/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если Python не первый сорт для клея, то я даже не знаю что тогда.
| | |
| |
| 6.113, Led (ok), 22:39, 26/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
 > Если Python не первый сорт для клея
Разве что нюхательного.
| | |
|
|
|
|
| |
| |
| 4.94, . (?), 03:31, 23/06/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
Попробуйте Pike. Это как раз для "писать скрипты на Си" ...
| | |
|
|
|
| 1.89, DV60 (?), 20:55, 22/06/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Опоздали.Есть Nim и использует GCC как надстройка по умолчанию не дожидаясь включения.
| | |
| 1.107, Вячеслав (??), 22:13, 25/06/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 А как решается вопрос о совмещении 1005000 компиляторов в одном?
(Я не техническую сторону вопроса имею в виду а организационно-управленческую: как это происходит - пишется стандарт взаимодействия, cогласовывается АPI, определяется политика? Может, проще разрабатывать не сам компилятор а специальный документ, описывающий математически верифицируемый и расширяемый общий интерфейс всех частей такой программы а также - грамматики описания поддерживаемого языка и налагать лицензионные ограничения свободного и открытого кода на всех кто им решит воспользоваться этими наработками в своих разработках. При этом остальные части программ пишут те, кому это нужно. Иначе компилятор "gcc" не осилит никогда даже поддержку и первых 150, по распространённости, языков программирования).
| | |
| |
| |
| 3.115, Вячеслав (??), 08:42, 27/06/2017 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Назови хотябы 35 широкоиспользуемых компилируемых языков
Это сделать не получится - потому что, наверное, большая часть их ещё не создана, но будет создана кем то и когда то в будущем - под возникшие потребности.
Уже сейчас, разным оценкам, в настоящее время существует от двух с половиной до десяти тысяч различных языков программирования: если понимать язык как инструментальное средство труда под названием "программирование", то можно сказать, что это аналоги инструментов труда, самых разнообразных - от самопальных, до профессионального заказного инструмента и оснастки для машиностроительных заводов.
И всё это придётся поддерживать с минимальными усилиями - во имя работы унаследованного кода (ситуация с Коболом в банках сейчас или будущие горы археологического кода на Java).
| | |
|
|
|
