Только Python. Слишком очевидно, чтобы ещё что-то пояснять.

c2lang.org

Хвалят/хвалили эликсир. Люди родом из веба. Оно транслируется в сишечку.

Нет, оно компилируется в байткод, который уже запускается на виртуальной машине Erlang (BEAM).

Смотрю тут многие Котлин предлагают в качестве замены. У него та же проблема что и у жабы — писать без IDE на нем крайне сложно

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

P.S. Но все что я написал, только мои догадки, сам не пробовал, нету такой задачи как у ТС.

Толсто.

Ada

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

Это, очевидно, более адекватные средства структуризации кода, отделения интерфейса от деталей реализации, модули, пространства имен. Мало того, что октава - плетущаяся за проприетарным оригиналом бесплатная реализация, матлабовский подход к тому же - либо один_файл==одна_процедура, либо какой-то костыльный ООП - приводит к написанию очень плохо структурированного кода, плохо поддающегося расширению и изменению. Даже такой древнющий язык как Фортран уже к стандарту 90го года севолюционировал до уровня модулей, а матлаб этого не осилил.

А зачем писать без IDE? Это челендж такой?

Не обязательно. В D есть rdmd, специально для таких вещей: https://dlang.org/rdmd.html

Это какой-то инструмент, позволяющий писать подобия скриптов на D? Ну хорошо, вообще есть интерпретаторы C.

Мой поинт в том, что концептуально такие инструменты не делают компилируемые языки скриптовыми, т.к. все равно система типов статическая и типы надо указывать, - пусть даже если система типов их выводит автоматически в некоторых случаях, - т.е. быстро набросать скрипт, как на питоне или перле уже не получится. T.e. можно и, с одной стороны, добавлять подобные «интерпретаторы», и, с другой стороны, убирать необходимость указывать типы явно в коде, но это не сделает ЯП одинаково удобным и для скриптов, и для компилируемых наиболее эффективно в наиболее эффективный код программ.

Наиболее ярко эта противоположность скриптовости и компилируемости проявляется в Джулии. ЯП задумывался как убийца одновременно Фортрана, Матлаба, Питона, С и должен был и генерить быстрый код, и быть удобным для быстрых экспериментов на коленке с удобным отображением результатов а ля Matlab, RStudio, или хотя бы те же питоновские ноутбуки в браузере.

В итоге получился такой монстр, с динамической типизацией, компиляцией на лету через LLVM, в котором самые простейшие вещи типа показа графика прямой из 10 точек занимает чуть ли не минуту, но в то же время невозможно просто и быстро скомпилировать код в обычный бинарник без кучи дополнительных библиотек. T.e. получился одновременно и хреновый Фортран, и хреновый Питон в одном флаконе.

Блин...

Я же говорю, что хочу Си, но с удобными структурами/контейнерами, менее хлопотным выделением памяти и (из того, что есть в C++) параметрическим полиморфизмом, например.

Ну, например, почему бы не открыть для себя те же абстрактные типы данных в С и не написать себе библиотечку (библиотечки) для работы с ними? Правда, можно её сразу заточить под свою предметную область, а можно как GLib использовать. Который типа универсален.

Но в обоих случаях можно просто писать на С.

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

Ну, например, чтобы не закатывать Солнце вручную. Как минимум это.

Это какой-то инструмент, позволяющий писать подобия скриптов на D?

Это возможность запускать D-шные програмки без предварительной компиляции. Конкретно в случае D получается весьма удобно, особенно если нужно какую-то логику писать. Типы выводятся автоматически, память подчищается автоматически, ошибки типизации обнаруживает компилятор.

Только Python. Слишком очевидно, чтобы ещё что-то пояснять.

Насколько я понял из списка кандидатов ТС, он рассматривает только типизированные языки.

А зачем писать без IDE? Это челендж такой?

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

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

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

А зачем ему это, если задача матлаба - быстрое прототипирование, и с нею он отлично справляется. Для серьезных вещей есть С или Фортран.

хорош

1+«1»
jquery
и легаси с коллбэками почему-то появляются повсюду, если не использовать прокрустово ложе Typescript. Если отбросить мистику (карма эпического говнокода), то это потому, что на JavaScript особенно легко говнокодить и он чуть ли не стимулирует это.

Это только для ублюдков, не осиливших современные стандарты. Promise, async/await… Ну а жоквери надо уже давно закапывать, современные API позволяют использовать всё куда эффективнее без подобных костылей.

Да уж прямо...

«Закат солнца вручную»... ADT на то и ADT чтобы быть абстрактными. В других-то языках их тоже кто-то же написал?

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

Что в этом плохого, если точно уверен в правильном поведении кода?

Именно, что прямо. Писать что-то на C вне потрохов Linux-а — это и есть закат Солнца вручную.

Тем более, делать самому библиотеку ADT, когда в любом более-менее современном языке готовых контейнеров на любой вкус.

За исключением любимой Ъ-программистами сишечки.

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

Go известен как очень быстрый компилятор. И очень легко используется в режиме скрипта:

//usr/bin/env go run $0 "$@"; exit
package main

import (
        "fmt"
        "os"
)

func main() {
        fmt.Println("Hello world!")
        cwd, _ := os.Getwd()
        fmt.Println("cwd:", cwd)
        fmt.Println("args:", os.Args[1:])
}

На компиляцию, запуск и отработку на мобильном sandy bridge уходит около 300 мс.

чего-то близкого по функциональности к скриптам, но за которым не надо будет носить интерпретатор

Cython? Пиши на питоне@компилируй в бинарник

Который будет зависеть от libpython.

Ну так...

За исключением любимой Ъ-программистами сишечки.

Это легко объяснимо. Кому-то ADT нужны, кому-то нет. Но все предполагают что либо программист сам может написать (если нужно), либо он может взять готовую библиотеку, уже реализующую нужное.

Писать что-то на C вне потрохов Linux-а — это и есть закат Солнца вручную.

GTK+ это далеко не потроха. Ничего, работает и там.

Который будет зависеть от libpython.

Ну и? Это ж рантайм, а не весь тулсет с интерпретатором. Можно вообще статически слинковать.

Больше всего твоим требованиям соответствует Go, нравится тебе это или нет. Заодно удивился тому, что ты рассматриваешь Vala, но без негатива.

D и Rust, я думаю, в твоём случае будут оверкиллом.

Кому-то ADT нужны, кому-то нет.

Вы уж определитесь: либо они нужны и тогда их нужно писать самому (вы ведь это предлагали, не так ли?), либо не нужны (тогда к чему был ваш совет?).

Но все предполагают что либо программист сам может написать (если нужно), либо он может взять готовую библиотеку, уже реализующую нужное.

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

GTK+ это далеко не потроха.

Это легаси.

Раз вы такой пропагандист использования чистого C, то легко сможете показать, как чистый C зарулит по простоте реализации вот этот тривиальный пример со стартовой странички сайта dlang.org:

void main()
{
    import std.range, std.stdio;

    auto sum = 0.0;
    auto count = stdin.byLine
        .tee!(l => sum += l.length).walkLength;

    writeln("Average line length: ",
        count ? sum / count : 0);
}

Это подсчет средней ширины строк на stdin-е.

Разработчики, например, Месы удивились, если бы узнали, что Дядя Женя запрещает им реализовывать контейнеры на C, и «закатывать солнце вручную».

Владимир

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

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

Пока никто не смог внятно ответить.

Racket — ещё бóльший оверкилл в этой ситуации, хотя, если ТС внезапно озадачится приятностью написания прикладного кода, то да.

Тем более, делать самому библиотеку ADT, когда в любом более-менее современном языке готовых контейнеров на любой вкус.

Готовые контейнеры оптимизированы для общего случая, и не всегда будут самым оптимальным выбором. Например, из-за требования стандарта C++ (https://stackoverflow.com/questions/21518704/how-does-c-stl-unordered-map-res...) unordered_map может быть медленнее самописного варианта. В интернете есть много примеров реализаций, которые быстрее в общем случае, либо на определенных наборах данных.

• https://www.ilikebigbits.com/2016_08_28_hash_table.html
• https://probablydance.com/2017/02/26/i-wrote-the-fastest-hashtable/
• http://www.reedbeta.com/blog/data-oriented-hash-table/

Владимир

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

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

Кроме того, вот эти ваши слова:

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

Лишь подтверждают то, до чего вы решили доколупаться:

в любом более-менее современном языке готовых контейнеров на любой вкус.

Реализации есть, даже для частных случаев, вы сами подтверждаете. Смысл писать самому ADT по-прежнему ускользает (особенно в условиях ТСа).

Мне интересно, зачем кому-то в здравом уме сейчас вручную писать свои контейнеры на чистом С.

В Месе, например, есть реализация хеш-таблицы и хеш-множества на C. Вопрос — на каком языке им стоило реализовывать эти структуры данных?

Владимир

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

На компиляцию, запуск и отработку на мобильном sandy bridge уходит около 300 мс.

И, если не ошибаюсь, уже скомпилированный исполняемый файл не будет компилироваться повторно, если исходник не изменён. Т.е. второй запуск просто вылетит в проверку last_mod двух файлов, один из которых в /tmp/ или $TMPDIR/.

Реализации есть, даже для частных случаев, вы сами подтверждаете. Смысл писать самому ADT по-прежнему ускользает (особенно в условиях ТСа).

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

Все ещё Владимир

Твой пример на D так же легко пишется на С. Просто немного больше строк будет — вот и все! Но у тебя в примере не чистый ЯП, а библиотеки используются → на C можно вообще в три строки это написать:

char *lineptr = NULL; size_t n = 0, i, total = 0, N = 0;
while((i = getline(&lineptr, &N, stdin)) > 0){ total += i; ++N; n=0; lineptr=NULL;}
printf("Average line length: %zd\n", N ? total/N : 0);

Вопрос — на каком языке им стоило реализовывать эти структуры данных?

Скажите честно, вам вера мозги заменяет?

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

Т.к. они пишут на C, то и реализации они делают на C.

Вроде бы все просто, с чем у вас здесь затруднения — не понятно.

Как и не понятно, зачем приплетать такой проект, как Mesa, в качестве примера в данной теме. Сможете пояснить, каким образом начатый в 1990-х годах проект отностится к проблеме выбора ТСа?

ruby
/thread

Ожидаемое C-шное говнецо. И оформлено соответствующе.

Память по адресу lineptr кто будет чистить?

Как и не понятно, зачем приплетать такой проект, как Mesa, в качестве примера в данной теме. Сможете пояснить, каким образом начатый в 1990-х годах проект отностится к проблеме выбора ТСа?

Я отвечал не автору темы, а на это ваше сообщение:

Именно, что прямо. Писать что-то на C вне потрохов Linux-а — это и есть закат Солнца вручную.

Вывод — вне потрохов Linux на C прекрасно пишется, структуры данных реализуются, выполняется всё довольно шустро, все довольны.

Владимир

Ну так, если бы все руководствовались принципом «просто используй готовое», то даже эти простенькие, но довольно быстрые реализации не были бы написаны

И вам я тоже вынужден сказать: отучаемся говорить за всех.

Я, например, был воспитан на таком подходе: сначала получаем работающее решение на уже имеющихся инструментах. А потом, если возникает надобность в оптимизации, отыскиваются реальные узкие места и они уже расшиваются тем или иным способом.

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

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

Ожидаемое C-шное говнецо. И оформлено соответствующе.

На D-шное говнецо посмотри! Его вообще прочесть нереально... Высер какой-то, а не код.

Память по адресу lineptr кто будет чистить?

Тьфу, плохо прочитал ман. Но я бы не использовал getline, а написал свой парсер.

вне потрохов Linux на C прекрасно пишется, структуры данных реализуются, выполняется всё довольно шустро, все довольны.

И в пример приводится какой-нибудь древний легаси, берущий свое начало в 1980-х или в 1990-х. При этом умалчивается и стоимость разработки, и количество ошибок, постоянно вылавливаемых в C-шных проектах.

Все довольны, ага. Перекреститесь еще раз.

на C можно вообще в три строки это написать

Там не про количество строк, а про понятен код или нет. Хоть в одну строку через «;» вытягивай, ситуации это не спасёт. И да, у него там вроде (я хз) приводится к флоту, а у тебя два size_t при делении разве не дадут обрезание дробной части? Я правда не знаю как это в D.

а про понятен код или нет.

Ну вот если бы ты не написал, что этот код делает, я бы не понял сходу. А в С все прозрачно и понятно.

а у тебя два size_t при делении разве не дадут обрезание дробной части?

А ничего, что символ - целое и неделимое число, там не должно быть флоатов.

Его вообще прочесть нереально... Высер какой-то, а не код.

Ну так если языка не знаешь, то как же читать?

Но я бы не использовал getline, а написал свой парсер.

И прощай понятность и лаконичность.

В общем, очередная демонстрация возможностей чистого С.

все довольны

Так довольны, что для Gnome/GLib в итоге сделали Vala

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

Если собирать go build script.go - да. Там же запуск:

//usr/bin/env go run $0 "$@"; exit

Повторный go build у меня занимает около 110 мс, запуск и исполнение практически ничего (около 5 мс).