Pascal, Assembler (в основном). Схемотехника.
Information
- Rating
- 5,181-st
- Location
- Россия
- Registered
- Activity
Specialization
Game Developer, Application Developer
Middle
Pascal
Lazarus
Assembler
Android development
Linux
MAC
QEMU
Game Development
Circuitry
Electronics Development
Держите, под 4 архитектуры и немного ссылок там же для информации.
Зная ассемблер под одну архитектуру, достаточно не сложно разобраться в другой архитектуре. Важно само понимание происходящего.
И именно на этом моменте я бы лучше книги почитал, потому что там информации на порядок больше, и больше разъяснений и примеров.
Вот ещё "Hello World!" на 4-х ассемблерах. )))
уточнение: для любых компилируемых ЯП, а не только для этих трёх.
Для желающих изучать нативную разработку в Android, обязательно пользуйтесь документацией. Там очень много полезного. И можете смотреть не только нативную часть, потому что зачастую надо именно переплетать java-код с нативным.
Жаль, что в статье мало раскрыта эта тема и нет ссылок.
"Простейшее", "быстрое решение".
Не использую слово "наивность" по отношению к программированию, вот и подумал о другом.
нативно?
У меня вечная проблема, что-нибудь увижу и надо это оптимизировать.
А надо или не надо, это уже другой вопрос. Хорошо хоть останавливаться умею иногда.
Перечитаю позже, и если не забуду займусь выводом в графическое окно. Пока текст только в терминал выводил.
Именно это я и постараюсь охватить в последующих статьях. То что я могу показать и то, что уже есть готовое. Основываться буду на тех ЯП что использую я, но постараюсь донести информацию так, чтоб её можно было использовать в большинстве ЯП, а не только тех которыми я пользуюсь.
Это отдельная тема, которую тоже достаточно не просто раскрыть. По сути, если делать подробнейший разбор, то это не на одну статью. Моя задача была пробежаться, охватить как можно больше народа и постараться донести основную мысль до людей. За которую они должны зацепится и выбрать нужное направление.
заходим в ютуб и вбиваем: "unity без кода". Получаем интересующие ответы.
да, новичку она полезна становится, по простой причине, что он начинает понимать что и в какой последовательности надо сделать.
Но я так понимаю, что вы можете предложить обзор всех ЯП чтоб я мог их приложить к статье и указать на вас, что вы сделали полный обзор и новички могут просто прочитать обзор и выбрать? Или вы всё-таки не предоставили такого обзора?
какие интересные вопросы от не новичка? А как же по вашему должен новичок узнавать какие первые шаги надо сделать, чтоб начать программировать? Спросить у мимо проходящего человека? Пойти учится на программиста? А вы точно уверены что новичок понимает что означает профессия "программист"?
Вот лично я не уверен что люди понимают что такое профессия "программист". Посмотрите вакансии программиста и посмотрите что там требуют.
Но вы предоставляете мне претензию по статье, где расписано по шагам что надо сделать по шагам. ))))
Они и раскрыты. Человек прочитает статью и поймёт, что и в какой последовательности делать. А не будет торкаться по интернету, сам не зная какой вопрос задать.
Многие даже не знают что есть такая профессия - "программист". И если вы этого не понимаете, то это бесполезный спор. Потому что вам надо как минимум понять, что человек может не знать банальных вещей. Он как ребёнок, которому надо указать направление и подсказать что и как называется.
На этом диалог завершаю. По причине вашего непонимания банальных вещей, с которыми вы сталкивались 20 лет (или более) назад и просто забыли об них.
Я надеюсь вы умеете эти очевидные вещи доносить до всех? Почему-то очевидные вещи, для большинства оказываются не очевидными. Не скажите почему?
ответ в статье.
в настоящее время нет. Потому что сотни ЯП, тысячи разных IDE не дадут в настоящее время нормальный вход в программирование. Может расскажите новичкам сколько на сегодняшний момент ЯП существует? Сколько сред разработки существует? Распишите всё подробно. Может тогда поймёте, что вхождение в программирование сейчас, это не то же самое что 20 лет назад, когда и выбора не было, пользовались тем что было и экспериментировали на каждом шагу.
Это не нам с вами решать. А самому человеку. многие люди для каких-то дел не созданы, но трудом и упорством достигали своей цели. Хотя все говорили что: "Это не ваше!".
Да, тут вы правы. Думаю надо будет доработать статью по данному направлению. Я больше смотрю как программист, а не человек который входит в игрострой, где уже многое готово.
Но надо как-то умудрится и не усложнить при этом саму статью.
Вы хотели чтоб я произвёл полный обзор всех ЯП? Всех IDE? Всех отладчиков?
Может тогда покажите пример? Я лично не решаюсь за такое браться. Но вот направить новичков таким образом, как раз можно. Потому что они как раз не знают даже что они ищут. Делая правильные шаги, они сделают верный выбор для себя.
Вы, вероятно, забыли, как вы выбирали ЯП? Сколько IDE перепробовали пока не пришли к той, что используете?
Новичков надо направить, а не прибить их гвоздями к какому-то пункту. Они сами "прибьются", когда решат какое направление им выбрать.
надо было более полно написать: "поставьте лайк/дизлайк".
По сути вопроса мог бы сказать что ты бежишь впереди паровоза, но вопрос резонный, так как остальных статей пока нет. Но в статье так и написано, что статьи будут. А вот в каждой статье отвлекаться на подготовку проекта (по необходимости) это будет не очень резонно. Поэтому данная статья для того чтоб человек мог подготовится к разработке, и мне не приходилось лишний раз отвлекаться на мелочи, которые важны для новичков.
Обратите внимание, если откроете книжки по программированию, то там не малая часть занимает именно подготовка к программированию.
И игрострой это так же касается.
Это ответ вам же. На любом другом ЯП будет абсолютно то же самое, если будет нормальное графическое редактирование. С полными функциональными возможностями.
И это не будет зависеть от вас, это будет зависеть от знаний человека, который с этим столкнётся. А точнее с каждым днём людей, которые будут редактировать форму вручную, будет всё меньше и меньше. И знаний о том, что её можно редактировать будет всё меньше и меньше. Пока человек не поинтересуется этим.
Повторюсь: при этом, в Lazarus и в Delphi есть возможность редактирования формы вручную. Как отдельный файл, так и в коде!
При том, что вам уже ответили, что такая возможность в Lazarus и Delphi существует. Писали об этом уже не один раз.
Основы как были так и останутся основами. И на каком бы ЯП они не были написаны, они всегда будут нести нужную информацию.
Это ответ, ради ответа. Сути ни какой не несёт, банальная попытка оправдать себя.
Для постоянного использования и сделан другой функционал, тот, который предоставляет полноценную замену.
Ни Lazarus ни Delphi не обязаны использовать тот же функционал, что используется в других языках. Ни один язык не пошёл по стопам Паскаля, и это их выбор. То что вы пишите, это так же очередная попытка оправдать самого же себя (свои слова).
Я думаю что дальше стоит вообще продолжать диалог, вы зациклены на своей стезе, в которой видимо застряли и не хотите признавать какие-то другие подходы.
то есть вы подтверждаете, что вы не читаете что вам пишут? Я конкретно сказал, что можно делать так, как захочешь, если умеешь это делать!
Что именно не нравится в ответе? Что мешает редактировать, при том что маловероятно этим будешь заниматься?
Я использовал это для переноса проекта Delphi в Lazarus. Очень маловероятно что этим будет пользоваться кто-то ещё, ведь в основном это нужно только для редактирования вещей, которые вызывают ошибку в данном модуле и должно это произойти из-за файла *.lfm.
Я же уже написал, данный дизайнер содержит практически все настройки, которые уже не надо прописывать вручную, а можно просто установить.
Да, можно в коде, без использования файла *.lfm прописать все свойства для формы. Вручную добавить кнопки, прописать их данные, связать их между собой по необходимости...
Да, можно, но тут как раз и возникнет вопрос: "А зачем?"
Всё сделано для пользователя, чтоб он не мучался и видел конечный результат. Да, кому-то это не нравится (мне в том числе), но большинство может достаточно быстро сделать необходимый макет и уже от макета создавать необходимый код.
Визуальная составляющая очень сильно вытягивает данные среды разработки.