The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

В состав GCC одобрено включение языка программирования D

21.06.2017 20:41

Разработчики коллекции компиляторов GCC объявили о принятии решения по включению в число поставляемых в составе GCC компиляторов фронтэнда GDC (Gnu D Compiler) и runtime-компонентов, необходимых для сборки программ на языке программирования D.

Процесс включения поддержки языка D в GCC начался ещё в 2011 году, но затянулся из-за необходимости приведения кода к соответствию требованиям GCC и проблем с передачей прав на интеллектуальную собственность компании Digital Mars, развивающей язык программирования D. Проблемы с интеллектуальной собственностью были достаточно быстро решены, но для решения технических проблем и синхронизации разработки с компилятором DMD потребовалось почти полностью переписать GDC.

Язык D использует статическую типизацию, обладает синтаксисом, схожим с C/C++, и обеспечивает производительность компилируемых языков, при этом заимствуя некоторые полезные возможности динамических языков в области эффективности разработки и обеспечения безопасности. Например, предоставляется поддержка ассоциативных массивов, косвенное определение типов, автоматическое управление памятью, средства параллельного программирования, опциональный сборщик мусора, система шаблонов, компоненты для метапрограммирования, возможность использовать библиотеки на языке C, а также некоторые библиотеки на C++ и Objective-C.

  1. Главная ссылка к новости (https://gcc.gnu.org/ml/gcc/201...)
  2. OpenNews: Для GCC подготовлен фронтэнд с поддержкой языка Rust, развиваемого проектом Mozilla
  3. OpenNews: Компания Google надеется на включение компилятора языка Go в GCC 4.6
  4. OpenNews: Компания Digital Mars намерена добиться включения в GCC компилятора для языка программирования D
  5. OpenNews: В состав GCC одобрено включение фронтэнда для языка Go
  6. OpenNews: Язык программирования D на пути к включению в состав GCC
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/46739-gcc
Ключевые слова: gcc, dlang
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (76) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 21:10, 21/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    >опциональный сборщик мусора

    опционально отключаемый же

     
     
  • 2.8, Аноним (-), 02:12, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    попробуй отключить его для стандартных либ
     
     
  • 3.26, Crazy Alex (ok), 10:47, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Давно не следил, но стандартную либу в этом плане правили. мроблема с том, что GC обеспечивает непоторые довольно важные плюшки, вроде бесплатных слайсов массивов. Но на этот счёт были варианты какие-то.
     
     
  • 4.67, 11111 (?), 12:32, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > GC обеспечивает непоторые довольно важные плюшки, вроде бесплатных слайсов массивов.

    Но зачем, если есть языки с бесплатными слайсами массивов без GC?

     
     
  • 5.69, Crazy Alex (ok), 13:23, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Нет их. И быть не может, во всяком случае, в общем виде. Либо слайс будет не бесплатным, а refcounted (что в многопоточной среде даалеко не бесплатно) либо его время жизни будет явно ограничено.

    А вот примерно так оно используется: https://www.reddit.com/r/programming/comments/6bt6n/why_is_dtango_so_fast_at_p - ссылка древняя, и сейчас дишный XML-парсер вряд ли самый быстрый в мире, да и Tango уже выкинули. Но сама техника живее всех живых.

     
     
  • 6.74, Алконим (?), 13:59, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Есть: rust.
     
     
  • 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 +/
         Может использовать сишные и плюснутые библиотеки, как раз переписав хидеры. Для гиков можно использовать в коде ассемблерные вставки.
         Программы компилируются очень быстро, да и по быстродействию не проигрывают сишным. Но исполняемые файлы получаются увесистые, так как тянут сборщик мусора.
     
     
  • 4.68, Crazy Alex (ok), 12:44, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Немного устаревшая информация насчёт увесистых. Они получались увесистые не потому, что тянут сборщик мусора, а потому что shared libraries не использовали. Как минимум для линукса было пофикшено пару лет назад: https://stackoverflow.com/questions/31366010/why-d-program-executable-is-big-a
     
     
  • 5.80, Mihail Zenkov (ok), 15:40, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Мне очень нравится D, но размер исполняемых файлов явно его слабая сторона. Shared libraries не спасает: размер поставки (bin+phobos.so) будет еще больше, чем для статики. Потребление памяти для простых приложений в любом случае очень сильно завышено (в сравнении с C).

    ИМХО основная проблема, что по-прежнему линкер не может выкинуть основную массу мертвого кода. Где-то было обсуждение этой проблемы, но сходу ссылку не найду.

    Есть еще страница (http://digger.k3.1azy.net/trend/), на которой отслеживалась тенденция размера исполнимых файлов в зависимости от версии, но что-то у меня она ошибку выдавать стала.

     
     
  • 6.83, Crazy Alex (ok), 16:51, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На 32-битной платформе libphobos.so занимает 6 мегабайт. Учитывая, что это всё же общий рантайм, я никакой проблемы не вижу ни для чего кроме каких-нибудь сборок OpenWRT.

    Насчёт потребления памяти - в первой паре тестов, которые мне попались, всё вполне прилично: https://github.com/kostya/benchmarks и https://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rus

    Надо бы ещё поискать, но как-нибудь потом.

     
     
  • 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 +/
    Нет, я всё понимаю когда люди изнывают, что нужно ради одной софтины тащить пол ... текст свёрнут, показать
     
     
  • 9.95, Mihail Zenkov (ok), 11:24, 23/06/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Зачем ориентироваться на худшее, а не на лучшее KolibriOS в 1 5 MB вкладывается... текст свёрнут, показать
     
     
  • 10.100, Crazy Alex (ok), 12:51, 24/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что важны затраты усилий и риски возникновения ошибок, в том числе в ходе... большой текст свёрнут, показать
     
     
  • 11.103, Mihail Zenkov (ok), 13:21, 24/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Не факт Производители по-прежнему хотят минимальной себестоимости К примеру на... большой текст свёрнут, показать
     
     
  • 12.108, Crazy Alex (ok), 15:13, 26/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На железе, где потребление ресурсов напрямую влияет на себестоимость, а обновлен... большой текст свёрнут, показать
     
     
  • 13.110, Mihail Zenkov (ok), 17:02, 26/06/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как я уже сказал - с этим согласен и для десктопных приложений использую D именн... большой текст свёрнут, показать
     
  • 13.111, Mihail Zenkov (ok), 20:37, 26/06/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сегодня похоже добили баг с ожирением из-за TypeInfo https forum dlang org po... текст свёрнут, показать
     
  • 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.7, gustav (?), 00:44, 22/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Хорошая новость=)
     
  • 1.11, Спайк (?), 03:19, 22/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    для полного фарша в GCC ещё Limbo добавить и будет совсем конанично. и да, ржавые напряглись! :)
     
     
  • 2.13, anonymous (??), 04:54, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ждём gcc-rust :-D
     
     
  • 3.14, Аноним (-), 07:45, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Уже есть https://www.opennet.ru/opennews/art.shtml?num=38576
     
     
  • 4.58, X4asd (ok), 11:34, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    вот этот коммит мне нравится :-) :-)

    https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=349ea0af3752bfb73a859e3ecb5ff63c1

     
  • 4.65, Crazy Alex (ok), 12:28, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот примерно так и GDC в 2011-м был ;-)
     
  • 3.61, Zloy (?), 11:43, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    гццуст
     
     
  • 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]

     
  • 3.97, Вареник (?), 07:56, 24/06/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Ждём gcc-rust-D

    - Сильно...

     
  • 2.15, nc (ok), 07:45, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Многие вещи в Go взяты из Limbo. А Go сейчас - последний язык в этой цепочке (Newsqueak - Alef - Limbo - Go). Так что в каком-то смысле уже есть.
     

  • 1.16, Аноним (-), 08:39, 22/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Кому интерфейсы с С++ нужны могут взять https://github.com/Syniurge/Calypso/ он даже Qt собирает.
     
     
  • 2.98, Вареник (?), 08:00, 24/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Кому интерфейсы с С++ нужны могут взять https://github.com/Syniurge/Calypso/ он даже Qt
    > собирает.

    Класс. Вот этом может взлететь.

     

  • 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.  Камрады _борются_ [I]![/I]

     
  • 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. Судя по гитхабу их там всё же четверо. А вещь на вид неплохая, пригодится.

     
     
  • 5.85, Аноним (-), 19:04, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    У dlin_hui название лучше.
     
  • 2.63, Александрик (?), 12:00, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Гномеры уже активно на Rust переползают, так что вряд ли.
     
     
  • 3.96, Аноним (-), 03:07, 24/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    откуда инфа?
     
     
  • 4.118, Аноним (-), 21:33, 12/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    http://lmgtfy.com/?q=gnome+rust
     
  • 2.73, Аноним (-), 13:59, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тут не только и не столько в расстановке кроватей проблема.
     

  • 1.75, анонимбр (?), 14:06, 22/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    (Как-то натыкался на такой проект) D программы быстро собираются поэтому вполне можно писать и скрипты на нем.
     
     
  • 2.78, Аноним (-), 15:19, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Скрипты с типизацией и с ООП? Да ну к черту вас.
     
     
  • 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 не первый сорт для клея

    Разве что нюхательного.

     
  • 2.88, dq0s4y71 (ok), 20:25, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скрипты можно и на Си писать, если уж так хочется - tcc.
     
     
  • 3.90, Pinkie (?), 21:54, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Можно. Но жутко неудобно и полно страданий
     
     
  • 4.94, . (?), 03:31, 23/06/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Попробуйте Pike. Это как раз для "писать скрипты на Си" ...
     
     
  • 5.99, funny.falcon (?), 08:23, 24/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ты его используешь? Поделись впечатлениями.
     

  • 1.89, DV60 (?), 20:55, 22/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Опоздали.Есть Nim и использует GCC как надстройка по умолчанию не дожидаясь включения.
     
  • 1.107, Вячеслав (??), 22:13, 25/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А как решается вопрос о совмещении 1005000 компиляторов в одном?
    (Я не техническую сторону вопроса имею в виду а организационно-управленческую: как это происходит - пишется стандарт взаимодействия, cогласовывается АPI, определяется политика? Может, проще разрабатывать не сам компилятор а специальный документ, описывающий математически верифицируемый и расширяемый общий интерфейс всех частей такой программы а также - грамматики описания поддерживаемого языка и налагать лицензионные ограничения свободного и открытого кода на всех кто им решит воспользоваться этими наработками в своих разработках. При этом остальные части программ пишут те, кому это нужно. Иначе компилятор "gcc" не осилит никогда даже поддержку и первых 150, по распространённости, языков программирования).
     
     
  • 2.114, Твой классный руководитель (?), 00:33, 27/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Назови хотябы 35 широкоиспользуемых компилируемых языков
     
     
  • 3.115, Вячеслав (??), 08:42, 27/06/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Назови хотябы 35 широкоиспользуемых компилируемых языков

    Это сделать не получится - потому что, наверное, большая часть их ещё не создана, но будет создана кем то и когда то в будущем - под возникшие потребности.
    Уже сейчас, разным оценкам, в настоящее время существует от двух с половиной до десяти тысяч различных языков программирования: если понимать язык как инструментальное средство труда под названием "программирование", то можно сказать, что это аналоги инструментов труда, самых разнообразных - от самопальных, до профессионального заказного инструмента и оснастки для машиностроительных заводов.
    И всё это придётся поддерживать с минимальными усилиями - во имя работы унаследованного кода (ситуация с Коболом в банках сейчас или будущие горы археологического кода на Java).

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру