Comments 77
Выберите язык «любой» из не сложных, на самом деле их очень много. Если сделать голосование, то начнется холивар, так как каждый из языков чем-то хорош, чем то супер классный и имеет какие-то недостатки.
Давайте начнем от противного, что стоит исключить:
С++ — сложноват, так как имеет очень много правил которые обязательны! Собственно все компилируемые языки нужно отбросить.
Java — начинать с ООП достаточно сложно, так как куча оберток которые ничего не делают, но НАДО! понять на первых этапах это тяжело.
Ruby — не могу что-то сказать, я с ним не сталкивался, но знакомые показывали куски кода, там черт ногу сломит
Basic, Pascal — считаю их бесполезными, так как учить их не сложно но применить в жизни сложнее. Я начинал с бейсика на спектруме, отличный язык для обучения, но скажем так что после обучения нужно забыть то что выучил, печаль
Из вариантов «ЗА» я бы отдал свой голос за Python, потому что:
— интерпритируемый
— при всей сложности, я считаю его простым
— при всей простоте, это очень сильный язык. Есть куда развиваться, можно посмотреть на Джанго
— кросплатформенный — огромнейший плюс
— кроме консоли несложно делать GUI приложения (например, тот же Бейсик меня стопорил тем что дальше расчета задачек на нем сложно поехать)
В целом достойно подать можно любой язык, важно подход в подаче для детей!!!
Давайте начнем от противного, что стоит исключить:
С++ — сложноват, так как имеет очень много правил которые обязательны! Собственно все компилируемые языки нужно отбросить.
Java — начинать с ООП достаточно сложно, так как куча оберток которые ничего не делают, но НАДО! понять на первых этапах это тяжело.
Ruby — не могу что-то сказать, я с ним не сталкивался, но знакомые показывали куски кода, там черт ногу сломит
Basic, Pascal — считаю их бесполезными, так как учить их не сложно но применить в жизни сложнее. Я начинал с бейсика на спектруме, отличный язык для обучения, но скажем так что после обучения нужно забыть то что выучил, печаль
Из вариантов «ЗА» я бы отдал свой голос за Python, потому что:
— интерпритируемый
— при всей сложности, я считаю его простым
— при всей простоте, это очень сильный язык. Есть куда развиваться, можно посмотреть на Джанго
— кросплатформенный — огромнейший плюс
— кроме консоли несложно делать GUI приложения (например, тот же Бейсик меня стопорил тем что дальше расчета задачек на нем сложно поехать)
В целом достойно подать можно любой язык, важно подход в подаче для детей!!!
Полностью поддерживаю. Авторам посоветовал бы еще посмотреть в сторону Minecraft Pi Editor. Для детей идеально.
Ruby обладает примерно теми же преимуществами, но в нём нет принципа «Явное лучше неявного», а скорее ровно наоборот.
> Java — начинать с ООП достаточно сложно, так как куча оберток которые ничего не делают, но НАДО! понять на первых этапах это тяжело.
А зачем начинать с ООП? Можно подойти к этому постепенно, планомерно двигаясь в этом направлении. А представить ребёнку основные принципы ООП можно образными примерами. Ещё стоит упомянуть небезызвестную книгу Файна Я. «Программирование на Java для детей, родителей, дедушек и бабушек».
А зачем начинать с ООП? Можно подойти к этому постепенно, планомерно двигаясь в этом направлении. А представить ребёнку основные принципы ООП можно образными примерами. Ещё стоит упомянуть небезызвестную книгу Файна Я. «Программирование на Java для детей, родителей, дедушек и бабушек».
А Java разве позволяет писать если не в «скриптовом» режиме (непосредственное исполнение инструкций в глобальном нэймспэйсе), то хотя бі в режиме С — одна функция типа main()?
Действительно, не учёл этой детали. В любом случае, когда начинают рассматривать примеры на Java, обычно опускают объяснение этих подробностей. Позже, естественно, возвращаются. Но правда ваша — работать непосредственно в «скриптовом» режиме намного легче и быстрее.
Kojo
Может показаться, что выбран слишком сложный язык. Но на базовом уровне он не сложнее Python или Ruby, а интергрированная среда со специальной библиотекой делают программирование в стиле Logo максимально простым. А наличие в языке сложных понятий дает простор для роста тем, кто почувствует вкус к программированию.
Может показаться, что выбран слишком сложный язык. Но на базовом уровне он не сложнее Python или Ruby, а интергрированная среда со специальной библиотекой делают программирование в стиле Logo максимально простым. А наличие в языке сложных понятий дает простор для роста тем, кто почувствует вкус к программированию.
По свему совсем недавнему детскому опыту могу судить, что обучение детей каким-то специфическим языкам (Domain Specific Language) это просто вредно для их будущего развития. Насчёт языка — C# идеален на мой взгляд, потому что одновременно избавляет от сложности C/C++, очень наглядный, очень грамотная среда (а среда это очень важно) и конечно же это серьёзный Си-подобный язык (production, «папа такой на работе использует» и всё такое).
В свое время классы ООП изучал вот по этой (Дрейер М. — C# для школьников) книжке, как это ни парадоксально. Очень понятно и доходчиво.
Вот эта говорят хорошая, удивился не встретив в посте.
На сайте издательства: link
На сайте издательства: link
Я бы проголосовал за C#, т.к. у него все понятно со средой, у него отличная документация, он используется в популярных движках (unity — все дети хотят игры делать), он не так сложен для начала, с его помощью можно и углубляться в ооп и продолжать дальнейшее изучение по всех сферах. Потом может пригодиться в жизни для работы и т.п.
у него все понятно со средой
С Mono Develope? :)
Реквестую книгу «UNIX для начальной школы»
Если серьезно, то я и выбрал c# именно из-за активной поддержки разработчиков самим MS
Если серьезно, то я и выбрал c# именно из-за активной поддержки разработчиков самим MS
С детства подсаживать детей на проприетарный софт, а их родителей на «донат» МС?
С такой точки зрения действительно хочется сразу рассказывать детишкам что такое «опенсорс», но боюсь танцы с бубнами для детей все же не лучший способ «ввода в специальность», даже не столько потому что сложно (дети шустро все схватывают), сколько может отпугнуть.
А насчет «доната» как раз и хотел уточнить, что постоянно появляются вохможности получить студиию бесплатно или какие-то еще материалы. Даже windows есть бесплатная для разработчиков на какой-то там срок, на «пощупать» хватает
А насчет «доната» как раз и хотел уточнить, что постоянно появляются вохможности получить студиию бесплатно или какие-то еще материалы. Даже windows есть бесплатная для разработчиков на какой-то там срок, на «пощупать» хватает
Express всегда была бесплатной, а возможностей там не меньше, чем у MonoDevelop.
Бесплатной не значит свободной. Может ли продвинутый ученик изучать и модифицировать исходные тексты?
Продвинутого ученика 8 лет, который будет модифицировать исходники IDE такого уровня, думаю сразу возьмут под личную опеку главы государства, не меньше…
В процессе обучения тяжело менять платформу. Что было в 8, может остаться и в 16, если само не вымрет.
Я абсолютно уверен, что менять платформу необходимо. Если вы знаете один язык, то вы его не знаете, пока не попробуете других. Знание одной методологии без знания других не позволяет полноценно использовать преимущества используемого языка. Например функциональные языки очень помогают по полной использовать и C# — , у меня есть проекты, где половина кода в написана в функциональном стиле, благо есть и лямбды, и замыкания, и все, что нужно. А знание низкоуровневых C\ASM помогают с написанием алгоритмов без диких кэш-промахов на ровном месте.
Кстати, я подобное мнение даже в интернете встречал у кого-то из Великих. Правда, я дошел до этого раньше, чем прочитал.
Кстати, я подобное мнение даже в интернете встречал у кого-то из Великих. Правда, я дошел до этого раньше, чем прочитал.
Хотел бы добавить, что с c# так же проще выходить в веб через ASP, чем через знания java. Разве нет?
Сложный выбор между Python и Ruby. Вы бы ещё JavaScript добавили :) Пожалуй, всё же Питон.
А можно уточнений, чем питон выйграл у руби? Просто интересно
Явное лучше неявного :) В Ruby достаточно много умолчаний и прочей магии, много способов сделать одно и то же без явных преимуществ одного на другим. Даже для опытного программиста не знакомого со спецификой языка код может быть неочевиден, хотя бы то что у каждой инструкции есть значение, а результатом функции/метода является результат последней инструкции является вещью из разряда «это нужно запомнить».
А можно пример «умолчаний и прочей магии»? Ну так, чтобы опытному программисту, незнакомому со спецификацией языка было не разобраться. Мне кажется, чтобы понять программу на любом языке, необходимо ознакомиться со спецификацией этого языка хотя бы вкратце. К слову сказать, говнокод можно написать на любом ЯП, что совершенно не говорит о корявости этого ЯП.
«много способов сделать одно и то же без явных преимуществ одного на другим» — а это скорее преимущество, т.к. каждый волен выбирать свой подход к решению задачи.
«много способов сделать одно и то же без явных преимуществ одного на другим» — а это скорее преимущество, т.к. каждый волен выбирать свой подход к решению задачи.
Устройте опрос среди знакомых программистов есть ли разница между тремя фрагментами кода:
Питон:
Си:
Руби:
Сколько из них скажут про то, что в Руби этот фрагмент будет возвращать значение 0 или nil, а переменная var будет задекларирована и проинициализирована nil даже если var1 не меньше ноля?
Это преимущество пока пишешь код, которій никто не будет читать.
Питон:
if var1 < 0:
var2 = 0
Си:
if (var1 < 0) {
var2 = 0;
}
Руби:
if var1 < 0
var2 = 0
end
Сколько из них скажут про то, что в Руби этот фрагмент будет возвращать значение 0 или nil, а переменная var будет задекларирована и проинициализирована nil даже если var1 не меньше ноля?
а это скорее преимущество, т.к. каждый волен выбирать свой подход к решению задачи.
Это преимущество пока пишешь код, которій никто не будет читать.
1. Возвращаемое значение условного выражения в данном примере вы нигде не используете, поэтому вам без разницы, возвращает оно что-то или нет.
2. Из всех приведенных примеров именно конструкция Питон выглядит наиболее замысловато.
3. Да, давайте все писать одинаковые программы, только идентичные подходы к написанию того или иного действия. За остальное — вывести на задний двор и расстрелять!
2. Из всех приведенных примеров именно конструкция Питон выглядит наиболее замысловато.
3. Да, давайте все писать одинаковые программы, только идентичные подходы к написанию того или иного действия. За остальное — вывести на задний двор и расстрелять!
1. Пускай, а с декларацией переменной что?
2. Что там замысловатого? Минимум лишних знаков, только:
3. Расстрелять не расстрелять, но уволить вполне могут за то, что не используешь идентичные подходы.
2. Что там замысловатого? Минимум лишних знаков, только:
3. Расстрелять не расстрелять, но уволить вполне могут за то, что не используешь идентичные подходы.
1. Я полагаю, что при первом же использовании, например var2 + что-то, вы сразу получите уведомление о том, что переменной не присвоено значение. Вполне логично, что при одном лишь упоминании переменной в коде она инициализируется «ничем» (nil).
2. Да, и еще никому неведомый (мы же говорим о не совсем знающем данный язык программисте) обязательный отступ. И границ окончания блока тоже как бы не наблюдается, что может ввести в замешательство при дальнейшем рассмотрении кода.
3. Я бы сам ушел с такой работы, где пресекают творчество.
2. Да, и еще никому неведомый (мы же говорим о не совсем знающем данный язык программисте) обязательный отступ. И границ окончания блока тоже как бы не наблюдается, что может ввести в замешательство при дальнейшем рассмотрении кода.
3. Я бы сам ушел с такой работы, где пресекают творчество.
1. Это не вполне логично, в случае если упоминание происходит внутри условного оператора, куда управление может и не передаться.
2. Из чтения кода не следует что он обязательный, есть отступ и есть. Не требуется прогнозировать что делать, если его не будет.
3. Сложно вам, наверное — в большинстве нормальных команд существуют соглашения о порядке использования тех или иных фич языка.
2. Из чтения кода не следует что он обязательный, есть отступ и есть. Не требуется прогнозировать что делать, если его не будет.
3. Сложно вам, наверное — в большинстве нормальных команд существуют соглашения о порядке использования тех или иных фич языка.
1. Тут можно долго спорить, логично или нет, но в данном случае Ruby делает некоторую работу за вас, как бы добавляя else; var2 = nil;. Я уже сказал о том, что в таком случае при использовании var2 вы все-равно наткнетесь на ошибку.
2. Вот о чем и речь, что при чтении кода не возникает даже мысли о том, что отступ тут является вообще частью управляющей конструкции. Так у кого больше неявного в таком случае, все так же у Ruby? ;-)
3. В большинстве нормальных команд люди доверяют друг другу и используют готовые модули, а не суют свои ноздри в исходники к друг другу, чтобы ткнуть носом: «аааа! смотрите все! он написал не по нашим правилам! бей его, ребята!»
2. Вот о чем и речь, что при чтении кода не возникает даже мысли о том, что отступ тут является вообще частью управляющей конструкции. Так у кого больше неявного в таком случае, все так же у Ruby? ;-)
3. В большинстве нормальных команд люди доверяют друг другу и используют готовые модули, а не суют свои ноздри в исходники к друг другу, чтобы ткнуть носом: «аааа! смотрите все! он написал не по нашим правилам! бей его, ребята!»
1.
2. у человека привыкшего к явному заданию блоков вызовет недоумение и конструкция типа
3. Coding conventions, code review и т. п. для вас пустой звук?
как бы добавляя else; var2 = nil;
В Ruby достаточно много умолчаний и прочей магии
2. у человека привыкшего к явному заданию блоков вызовет недоумение и конструкция типа
var2 = 0 if var1> 0. В лучшем для руби случае 1:1 — без учёта того, что для питона одно правило про отступы для всех конструкций, а в руби границы блоков задаются у чуть ли не у каждой конструкции по своему. 3. Coding conventions, code review и т. п. для вас пустой звук?
1. Даже эти умолчания не мешают естественному и ожидаемому выполнению программы, так что если даже вы не в курсе каких-то умолчаний, то вам это не помешает
2. Ну а это уже более продвинутые конструкции, которые можно достаточно легко освоить, а при обучении языку на первых парах вообще не затрагивать такого вида конструкции — можно написать так, как другим понятно, или как для вас удобнее. А читается вообще как по человечески: a = 0 если то-то и то-то. Это и есть выразительная мощь языка!
«руби границы блоков задаются у чуть ли не у каждой конструкции по своему» — да неужели? вот новость-то!
3. Я привык к творчеству, свободному полету мысли, изобретениям, если так угодно, а не ходить строем по плацу.
2. Ну а это уже более продвинутые конструкции, которые можно достаточно легко освоить, а при обучении языку на первых парах вообще не затрагивать такого вида конструкции — можно написать так, как другим понятно, или как для вас удобнее. А читается вообще как по человечески: a = 0 если то-то и то-то. Это и есть выразительная мощь языка!
«руби границы блоков задаются у чуть ли не у каждой конструкции по своему» — да неужели? вот новость-то!
3. Я привык к творчеству, свободному полету мысли, изобретениям, если так угодно, а не ходить строем по плацу.
Соглашусь с утверждением об умолчаниях. Язык предполагает наличие программерского мышления. Откуда оно возьмётся у детей — непонятно. Не отрицаю, что с хорошей книгой можно научить ребёнка Ruby. Но ведь есть более простые инструменты для знакомства сс программированием: Python, Squeak, Lego Mindstorm.
wikipedia
Язык следует принципу «наименьшей неожиданности»: программа должна вести себя так, как ожидает программист. Однако в контексте Ruby это означает наименьшее удивление не при знакомстве с языком, а при его основательном изучении. Сам Мацумото утверждает, что целью разработки была минимизация неожиданностей при программировании для него, но после распространения языка он с удивлением узнал, что мышление программистов похоже, и для многих из них принцип «наименьшей неожиданности» совпал с его принципом.
По JavaScript кстати готовится книга для детей от NoStarch (см. PythonForKids выше): www.nostarch.com/jsforkids
Руби прост, но менее очевиден, нежели Python.
Сложно найти что-то проще Smalltalk-а. Тем более, что он изначально был создан для детей.
Squeak: Learn Programming with Robots
В качестве неплохой визуально-ориентированной альтернативы имеются Scratch и eToys.
Squeak: Learn Programming with Robots
В качестве неплохой визуально-ориентированной альтернативы имеются Scratch и eToys.
Я бы всё-таки хотел увидеть Hello Ruby от Линды на русском. Как раз дочка подрастает.
Я за Ruby. Это субъективное мнение программиста с более чем 20-летним опытом программирования на разных языках. Я изучал и программировал на нескольких языках — Basic, Pascal, C, C++, Delphi, Java, Perl, PHP и вот сейчас Ruby. Мое личное мнение — Ruby — лучший из всех тех, с чем я когда-либо работал. На нем можно писать как совсем простенькие программы, понятные детям, так и сложные системы — для любого он подойдет, не навязывая изначально никакой сложности в использовании — хотите просто — будет просто, хотите более сложно — и для этого возможности есть. При всем при этом очень ясны, понятный, логичный и лаконичный синтаксис. Очень красивый язык программирования.
Кстати, о Python (да простят меня гуру за мелкий мусор в их огород)… мне хватило только одного факта, чтобы даже не начать изучать его — анахронизм с обязательными отступами как часть синтаксиса языка. Давайте не будем ломать детям мозг отступами. Сразу почему-то вспоминаются нумерованные строки в Бейсик.
Кстати, о Python (да простят меня гуру за мелкий мусор в их огород)… мне хватило только одного факта, чтобы даже не начать изучать его — анахронизм с обязательными отступами как часть синтаксиса языка. Давайте не будем ломать детям мозг отступами. Сразу почему-то вспоминаются нумерованные строки в Бейсик.
>Сразу почему-то вспоминаются нумерованные строки в Бейсик.
Копайте глубже. Отступы на перфокартах в фортрановском коде.
Копайте глубже. Отступы на перфокартах в фортрановском коде.
Это как раз-таки хорошо. Многие функциональные языки так же делают (например, F#). Потому что даже автоформатирование в студии некоторые таланты умудряются запороть и писать код так, что его потом лучше и не читать никому и никогда. Строгость и привычка к стилю кодирования — очень мощная вещь, и лучше так вот жестко заставлять писать код с выравниваниями, чем мучиться. В конце концов, с опытом, человек сам придет к тому, что писать код нужно понятно для других, либо так и останется быдлокодером, с которым никто работать не хочет, зато он «незаменим» в своем маленьком мирке, т.к. пишет код только для себя в авторском стиле.
Да, во всем нужно видеть плюсы, согласен — лучше в Python с этим смириться и назвать преимуществом, потому что избавиться от этого все-равно не получится. Но вот только вы попробуйте ясно это изложить ребенку и не с позиций того, что его программу будет потом кто-то читать, а для чего эти отступы так важны для написания самого алгоритма. По себе помню, как лишние детали очень отвлекают от сути и очень мешают процессу обучения.
За последние несколько лет объяснил это уже порядка 50 детям. Отлично получается — через два занятия большинство из них практически не задумывается об отступах! До этого учили их на Паскале и С++, приходилось по много времени тратить на объяснение, зачем нужно правильное оформление (тут надо заметить, что правильное оформление — это не только отступы, но и, например, пробелы вокруг и после «знаков препинания»).
Вы считаете, что из всего, что ребенку предстоит выучить по программированию, именно отступы в первую очередь сломают ему мозг?
Я еще не видел проекта, где отступы бы не использовались для выделения блоков кода, потому что без них сколько-нибудь сложный код становится абсолютно нечитаемым.
Я еще не видел проекта, где отступы бы не использовались для выделения блоков кода, потому что без них сколько-нибудь сложный код становится абсолютно нечитаемым.
И отступы в том числе, а не именно они. Отступы должны преподаваться как стиль хорошего написания, как настоятельная рекомендация, показанная и доказанная на примерах, а не как обязательное и непременное условие, влияющее на ход исполнения программы.
Я прекрасно понимаю, что для питонистов это уже только благо, неизбежное благо. Не нужно только холиваров по этому поводу, я лишь высказал свое субъективное мнение по поводу особенностей синтаксиса Python.
Я прекрасно понимаю, что для питонистов это уже только благо, неизбежное благо. Не нужно только холиваров по этому поводу, я лишь высказал свое субъективное мнение по поводу особенностей синтаксиса Python.
Вы никогда не сталкивались с тем, что детям проще сказать «нельзя», чем объявнять краевые условия, когда это допустимо? Если не затрагивать вопросы этики, то возьмем математику
Детский сад. Из большего нельзя вычитать меньшее.
Младшая школа. Можно вычитать из большего меньшее, но нельзя делить четное число на нечетное.
Средняя школа. Можно делить четное на нечетное, но нельзя делить на ноль.
Старшая школа. Можно делить на ноль, но нельзя взять корень из отрицательного числа.
Первый курс. Можно взять корень из отрицательного числа, но нельзя проинтегрировать дискретную функцию вроде функции Дирихле.
Второй курс. Введем понятия меры…
Проще сначала сказать, что что-то сделать нельзя, а потом, когда человек сможет осознать, можно ему пытаться что-то объяснить. А то, вы вместо того, чтобы убрать ребенка от раскаленной плиты, к которой он тянется, начнете говорить про термодинамическое воздействие молекул газа с повышенным уровнем энергии на кожные покровы теплокровных млекопитающих.
Детский сад. Из большего нельзя вычитать меньшее.
Младшая школа. Можно вычитать из большего меньшее, но нельзя делить четное число на нечетное.
Средняя школа. Можно делить четное на нечетное, но нельзя делить на ноль.
Старшая школа. Можно делить на ноль, но нельзя взять корень из отрицательного числа.
Первый курс. Можно взять корень из отрицательного числа, но нельзя проинтегрировать дискретную функцию вроде функции Дирихле.
Второй курс. Введем понятия меры…
Проще сначала сказать, что что-то сделать нельзя, а потом, когда человек сможет осознать, можно ему пытаться что-то объяснить. А то, вы вместо того, чтобы убрать ребенка от раскаленной плиты, к которой он тянется, начнете говорить про термодинамическое воздействие молекул газа с повышенным уровнем энергии на кожные покровы теплокровных млекопитающих.
kdb ;-)
Вполне успешный в коммерческом плане проект…
Вполне успешный в коммерческом плане проект…
Главное, не Pascal, Delphi, Basic etc. Именно из за них у меня возникли сложности с пониманием ООП. Учить нужно то, что может понадобиться практически.
И чем ООП в Pascal отличается от ООП допустим в С++?
А во многих образовательных учреждениях учат ООП на Pascal и как часто его используют на практике? С процедурным программированием их и так в школе познакомят. IDE Delphi многое делает самостоятельно, соответственно, уровень понимания кода на старте ниже. Cpp же, как пример, хороший выбор. Кстати, моя знакомая преподает его школьникам в нашем городе в рамках внеурочных занятий. По ее словам, для тех, кто этого действительно хочет, вполне успешно.
Во многих образовательных учреждениях учат ООП на c++? Обычно это происходит так. Дети сегодня мы изучаем язык Си. Язык си процедурный, вот вам функция printf. Через пару недель. А теперь мы изучим С++. Он как Си только круче и объектно ориентированый. вот смотрите вместо printf надо писать cout <<. Видите как здорово?
Вот именно, что в рамках внеурочных занятий. Я был бы в школе счастлив, если бы нам давали на факультативе плюсы, а не я давал основы Си преподу.
Ничего не имею против Ruby или Python, но не понимаю одной вещи — насколько мне известно один из самых простых языков сейчас (который, собственно получил свою популярность, благодаря, своей простоте, это РНР. Сколько видел статей про этот язык (как положительных, так и отрицательных), везде говорят, что на нём пишут много программистов потому, что у него почти самый низкий порог вхождения.
Учитывая это, не понимаю, почему он не рассматривается?
Учитывая это, не понимаю, почему он не рассматривается?
Lua?
Имхо неплохой вариант, как и Python. Простой синтаксис, очень ненагруженный и интуитивный. Мультипарадигменный (т.е. позволяет начать с императивного программирования и ненавязчиво перейти к основам ФП). Эти два рассматриваю всегда в первую очередь, если спрашивают с чего лучше начинать учить программирование. Из недостатков — мало литературы и статей в интернете. И еще, для детей для обучения очень желательно написать какую-то библиотеку с примитивами графики (спрайтов в т.ч.) и звука. Так как учить детей нужно не на голых абстракциях, а так чтобы эти абстракции визуально можно было наблюдать.
Для подростков — Python, Си, может быть Процессинг. Для детей 5-12 лет Scratch идеален. Я вам написала письмо по адресу в статье.
Basic + Python. Первый применяется мало, но изучается легко, дает понять что такое программирование. Когда дети поймут ЧТО они делают, то можно переходить на питона.
Для тех, кто по старше — Pascal/Delphi для начала. У них более-менее простой синтаксис для понимания, без заморочек с памятью и указателями.
Для тех, кто по старше — Pascal/Delphi для начала. У них более-менее простой синтаксис для понимания, без заморочек с памятью и указателями.
This Java book.
Как насчет Processing?
Sign up to leave a comment.
Hello Ruby, или как научить ребенка программировать?