Metaprog: универсальная графическая среда программирования [в разработке] часть 3

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

Примеры и я могу в гимпе нарисовать. Говоря вашими (на самом деле Линуса) цитатами «Show me the code!»

Какие примеры? Ты о чем? Картинки? Это не примеры это херня.

Я тоже вот язык изобрел вот пример:

1234567890LDFJ*#

И это полный аналог опенофиса я тут написал, дада, верьте мне.

Вам примеры трансляции в код посложнее хеллоуворлда? Еще не вечер, когда воплощу указатели на функции - будет пример с открыванием окошка и графикой (повторю тот, что мне показали).

Ты хоть знаешь чем отличается массив от списка?

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

сей товарищ не знал...

А зачем я сюда по-вашему пришел? В основном чтоб узнать то, чего не знал. И узнаю. От вас, должен признать, есть польза проекту, хоть вы и критикан:)

Какие еще списки? struct?

страшно представить как на своей метаподелке он будет балансировать деревья. Очень хочу на этого мутанта посмотреть.

когда воплощу указатели на функции

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

Какие еще списки? struct?

Я аж в голосину.

Исходники? Они в бинарном формате и завязаны на транслятор, сделанный в Лабвью. А так скрины я показал, сгенерированный код показал.

хоть вы и критикан

Discussio mater veritas est.

Какие еще списки?

Приведу (не дословную) цитату вашего любимого Линуса: «Каждый, кто хоть раз пробовал программировать на C, первым делом после Hello, world пытается релизовать связанный список».

Вы же хвастались, что «просмотрел ту книгу по диагонали - и все понятно», ЕМНИП в «той книге» реализация связанного списка где-то в первой половине (могу ошибаться, давно было)…

Попробуйте выразиться по-сишному что такое связанный список. Наверняка я его 100 раз реализовывал в Лабвью, но не знал что это так называется.

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

Ну все. Теперь он очередную очивку в резюму напишет :D

Резюме тролля 80lvl разве что.

Какие деревья? Мы тут программированием занимаемся, а не садоводством!

ОП, посмотри на glib кстати! Поизучай ее! https://developer.gnome.org/glib/stable/glib-Singly-Linked-Lists.html https://developer.gnome.org/glib/stable/glib-Doubly-Linked-Lists.html

Мне кажется, все в этом треде занимаются трепом :)

Зачем вообще линкед листы? Почему не массив указателей? А точнее массив из кластеров с указателем и длиной массива:

struct {
int array_size;
byte * array_pointer;
} string_list[];

RTFM or GTFO. Это написано в любой книжке «Программирование для чайников». Надоел такой тупой и толстый тротлинг.

RTFM это долго и неэффективно. Проще спросить. И так, зачем вообще линкованные списки? В принципе, ничего нереального в том, чтоб реализовать кластер из данных и указателя на следующий такой же кластер нет (Метапрог поддерживает указатели), но зачем?

Скорость доступа, вставки, изменения и прохода по списку не совпадает с этими характеристиками у массива. Нужно это для того, чтобы вместо говнокода (типа GMail) (который вы так люто ненавидите) писать нормальный код (вроде ядра Linux). RTFM.

Разная с чем? Почему не массив указателей? Или даже массивы указателей на массивы указателей итд?

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

Реализуйте linear-time zero-copy safe insertion для массива указателей, массива указателей на массивы указателей и так далее.

Linear относительно количества вставляемых элементов, конечно.

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

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

А, теперь понятно. Можно быстро вставлять элемент. Хорошая идея если что.

Именно так мы и получили современный веб.

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

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

По такой логике на десктопе вообще приложений не должно быть

А причем тут приложения и онлайн книжки/форумы (веб)?

При том, что современный веб - именно что приложения с тоннами JS.

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

Т.е. если дятел написал факториал рекурсивно

Факториал должен быть в стандартной библиотеке! Вот отрисовку HTML криво написать нельзя, ее просто вшили.

При том, что современный веб - именно что приложения с тоннами JS.

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

Ввели бы что нибудь вшитое, быстрое, сразу бы на это все перешли.

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

Вшитое и очень быстрое уже есть - ванильный жс.

Но там ничего нету, как реактивные приложения делать то? А виджеты свои?

Очень просто - берешь и делаешь (c)

Я не против фреймворков как таковых, я против использования фреймворков без понимания того, как они работают. Если у вас реально большое и сложное приложение с кучей функционала и контента и при этом по объективным причинам ему не место на десктопе - пользуйтесь фреймворками, но в разумных пределах. А когда вместо 15 строк джаваскрипта подключается 7 фреймворков с 150МБ зависимостей, получается классическое «200 метров жабаскрипта грузят текста 300 байт»

А когда вместо 15 строк джаваскрипта подключается 7 фреймворков с 150МБ зависимостей

Например?

GMail.

Ох лол, ну так им платят за код просто (работникам гугла), не могут же они все быстро написать и уйти.