Иногда я скатываюсь до прогнозов.
Мои навыки программирования меняются и дополняются со временем. Основные идеи, которые со временем я добавил в свой багаж и широко использую в разработке программ.
1) Когда-то очень давно пробовал силы в С++ Java и т.п. Потом от всего этого отказался. Концепция объектно-ориентированного программирования должна быть в сердце, в уме, но не на языке. Объектно-ориентированному программированию без С++ ставлю плюсик.
2) Модульное программное обеспечение. Это когда объект (протокол) может регистрировать себя в системе. Использую статические конструкторы и деструкторы. Иногда использую технику регистрации без кода, на этапе линковки.
3) Многопоточные программы. Практически все проекты пишу с тредами.
Использую механизмы синхронизации процессов. Атомарные операции, мьютексы всякие премудрости.
4) Написание программ с векторными расширениями. Практически все алгоритмы обработки данных делаю с использованием векторных расширений языка С, GCC. Чтобы не сильно пугать людей скажу, векторные расширения добавляют всего две операции: определение векторного типа и операция shuffle. Остальное выражается средствами языка Си.
5) Обратил внимание на стандарт C11 из него собираюсь использовать атомарные операции. Вернее намерен в ближайшее время привести свои наработки по атомарным операциям к стандарту С11. Кроме того, меня взаправду обеспокоило, то что потоки и всякие примитивы синхронизации процессов стали частью языка. Когда-то, открыв книжку кернигана и ричи я понял что это язык с библиотеками, который получился таким ради Юникса. Сегодня понимаю, что язык начинает менять операционные системы. С этим надо считаться. То что привнесли в Си мне не нравится, а когда мне что-то нравилось. Но я объясню, что. Из него надо вытряхнуть большую часть библиотек, которые тянутся исторически для совместимости. Прикольно то, что стандарт является отражением Юникса. Но ведь мне навязывают, что в моей операционке должно быть. И то что мне навязывают, не отличается надежностью. Меня интересует другой концепт. Как в самом API заложить меньше ошибок, как сделать систему надежнее, за счет API, как сделать систему прогнозируемой, как уменьшить количество динамически распределяемой памяти.
6) Надо научиться писать программы для гетерогенных систем. Мой прогноз состоит в том, что развитие процессоров пошло в этом направлении, даже на ноутбуке, планшете и в скором времени на смартфоне можно обнаружить множество вычислительных узлов, которые простаивают. Когда-то мы осваивали вычислительные кластеры и для программирования использовался интерфейс MPI, сейчас распространение получил интерфейс OpenCL. Для гетерогенных систем оказывается важно, чтобы код собирался под операционную систему под конфигурацию и тип процессора из исходного кода. Однако когда я пытаюсь хоть что-то описать в духе OpenCL, API хоста не удобен, я пишу иначе, но с теми же концепциями синхронизации. Явным образом обрабатывать множество cl_event наверное неудобно, надо какой-то движок придумать или уметь генерировать таблицы событий статически. Я думаю в сторону потокового программирования и описания программ в виде блочных диаграмм и последовательностных диаграмм.
7) Есть кое-что, я никак не могу нащупать, но видимо -- это синтез программ. Мне нужен инструмент, который позволяет часть обработки провести на этапе компиляции. Есть множество операций, которые мне не сделать без предварительного синтеза кода. Одна такая область - компиляторы, не удобно писать компиляторы, нужен препроцессор, который слепит магический кристалл по описанию языка. Такая же проблема с разбором структурированных форматов, чтобы сопоставить строкам уникальные идентификаторы, надо их предварительно выделить, таблицу констант сразу не описать. Код надо иногда синтезировать.
8) Мир заболел одним синдромом. Суперкомпьютеры делают ради обучения, при этом никто не говорит, что такое обучение. Производители процессоров говорят, что процессоры должны быть параллельные, потому что задачи такие. На самом деле задачи параллельные -- это бред, они не могут сделать компьютер быстрым, вместо этого делают много маленьких. Но есть кое что в этой идее, нужен интерфейс, который позволит писать программы полиморфные. Очень сложно в одиночку создавать программу, и охватить знаниями одного человека задачи сложно, тут нам грозит либо кризис, либо прорыв. Я лично за кризис, меня вдохновляет идея быть хранителем знания в постапокалиптическом обществе и воплощать в одиночку проекты, давно потерянным искусством. Но тут жопа в том и состоит, что кризиса не будет, будет прорыв в Artificial intelligence (интеллектуальных программ). Пока что я усвоил одно -- хороший API способен творить чудеса и определять будущее на годы вперед. Я бы говорил про API, программный интерфейс для разработки интеллектуальных программ. Сейчас ведь не удивишь никого авто-завершением строк.
Когда волна пройдет и мир наполнится процессорами с 64 ядрами на кристалле, очередное поколение "погромистов" в очередной раз поймет, что на нейронных сетях без модели делать нечего, мы будем говорить о много-поточном движке, параллельных языках программирования и моделях обработки, и да движок должен синтезировать код из модели и работать на гетерогенной архитектуре, к которой нас ведет индустрия.
надо бы освежить тему: Транспьютер Марс + язык Модула-2.
Мои навыки программирования меняются и дополняются со временем. Основные идеи, которые со временем я добавил в свой багаж и широко использую в разработке программ.
1) Когда-то очень давно пробовал силы в С++ Java и т.п. Потом от всего этого отказался. Концепция объектно-ориентированного программирования должна быть в сердце, в уме, но не на языке. Объектно-ориентированному программированию без С++ ставлю плюсик.
2) Модульное программное обеспечение. Это когда объект (протокол) может регистрировать себя в системе. Использую статические конструкторы и деструкторы. Иногда использую технику регистрации без кода, на этапе линковки.
3) Многопоточные программы. Практически все проекты пишу с тредами.
Использую механизмы синхронизации процессов. Атомарные операции, мьютексы всякие премудрости.
4) Написание программ с векторными расширениями. Практически все алгоритмы обработки данных делаю с использованием векторных расширений языка С, GCC. Чтобы не сильно пугать людей скажу, векторные расширения добавляют всего две операции: определение векторного типа и операция shuffle. Остальное выражается средствами языка Си.
5) Обратил внимание на стандарт C11 из него собираюсь использовать атомарные операции. Вернее намерен в ближайшее время привести свои наработки по атомарным операциям к стандарту С11. Кроме того, меня взаправду обеспокоило, то что потоки и всякие примитивы синхронизации процессов стали частью языка. Когда-то, открыв книжку кернигана и ричи я понял что это язык с библиотеками, который получился таким ради Юникса. Сегодня понимаю, что язык начинает менять операционные системы. С этим надо считаться. То что привнесли в Си мне не нравится, а когда мне что-то нравилось. Но я объясню, что. Из него надо вытряхнуть большую часть библиотек, которые тянутся исторически для совместимости. Прикольно то, что стандарт является отражением Юникса. Но ведь мне навязывают, что в моей операционке должно быть. И то что мне навязывают, не отличается надежностью. Меня интересует другой концепт. Как в самом API заложить меньше ошибок, как сделать систему надежнее, за счет API, как сделать систему прогнозируемой, как уменьшить количество динамически распределяемой памяти.
6) Надо научиться писать программы для гетерогенных систем. Мой прогноз состоит в том, что развитие процессоров пошло в этом направлении, даже на ноутбуке, планшете и в скором времени на смартфоне можно обнаружить множество вычислительных узлов, которые простаивают. Когда-то мы осваивали вычислительные кластеры и для программирования использовался интерфейс MPI, сейчас распространение получил интерфейс OpenCL. Для гетерогенных систем оказывается важно, чтобы код собирался под операционную систему под конфигурацию и тип процессора из исходного кода. Однако когда я пытаюсь хоть что-то описать в духе OpenCL, API хоста не удобен, я пишу иначе, но с теми же концепциями синхронизации. Явным образом обрабатывать множество cl_event наверное неудобно, надо какой-то движок придумать или уметь генерировать таблицы событий статически. Я думаю в сторону потокового программирования и описания программ в виде блочных диаграмм и последовательностных диаграмм.
7) Есть кое-что, я никак не могу нащупать, но видимо -- это синтез программ. Мне нужен инструмент, который позволяет часть обработки провести на этапе компиляции. Есть множество операций, которые мне не сделать без предварительного синтеза кода. Одна такая область - компиляторы, не удобно писать компиляторы, нужен препроцессор, который слепит магический кристалл по описанию языка. Такая же проблема с разбором структурированных форматов, чтобы сопоставить строкам уникальные идентификаторы, надо их предварительно выделить, таблицу констант сразу не описать. Код надо иногда синтезировать.
8) Мир заболел одним синдромом. Суперкомпьютеры делают ради обучения, при этом никто не говорит, что такое обучение. Производители процессоров говорят, что процессоры должны быть параллельные, потому что задачи такие. На самом деле задачи параллельные -- это бред, они не могут сделать компьютер быстрым, вместо этого делают много маленьких. Но есть кое что в этой идее, нужен интерфейс, который позволит писать программы полиморфные. Очень сложно в одиночку создавать программу, и охватить знаниями одного человека задачи сложно, тут нам грозит либо кризис, либо прорыв. Я лично за кризис, меня вдохновляет идея быть хранителем знания в постапокалиптическом обществе и воплощать в одиночку проекты, давно потерянным искусством. Но тут жопа в том и состоит, что кризиса не будет, будет прорыв в Artificial intelligence (интеллектуальных программ). Пока что я усвоил одно -- хороший API способен творить чудеса и определять будущее на годы вперед. Я бы говорил про API, программный интерфейс для разработки интеллектуальных программ. Сейчас ведь не удивишь никого авто-завершением строк.
Когда волна пройдет и мир наполнится процессорами с 64 ядрами на кристалле, очередное поколение "погромистов" в очередной раз поймет, что на нейронных сетях без модели делать нечего, мы будем говорить о много-поточном движке, параллельных языках программирования и моделях обработки, и да движок должен синтезировать код из модели и работать на гетерогенной архитектуре, к которой нас ведет индустрия.
надо бы освежить тему: Транспьютер Марс + язык Модула-2.
Комментариев нет:
Отправить комментарий