Комментарии 438
JS как первый язык?
Вот результаты одного весьма серьёзного теста производительности для различных языков программирования.
А можно ссылочку?
Подозрительно низкая производительность ассемблера объясняется дубовой прямолинейностью asm-кода (например, счётчики вложенных циклов постоянно перекидываются из регистра в регистр, хотя вполне можно было выделить каждому счётчику по регистру).
%include "io.inc"
section .text
global CMAIN
CMAIN:
;mov rbp, rsp; for correct debugging
; Set to 0, the faster way
xor esi, esi
DO_LOOP1:
mov ecx, 10
LOOP1:
mov ebx, ecx
jmp DO_LOOP2
LOOP1_CONTINUE:
mov ecx, ebx
loop LOOP1
jmp QUIT
DO_LOOP2:
mov ecx, 32000
LOOP2:
mov eax, ecx
;call DO_LOOP3
jmp DO_LOOP3
LOOP2_CONTINUE:
mov ecx, eax
loop LOOP2
jmp LOOP1_CONTINUE
DO_LOOP3:
; Set to 32000 loops
MOV ecx, 32000
LOOP3:
inc esi
cmp esi, 50
jg COUNTER_TO_0
LOOP3_CONTINUE:
loop LOOP3
;ret
jmp LOOP2_CONTINUE
COUNTER_TO_0:
; Set to 0
xor esi, esi
jmp LOOP3_CONTINUE
; jmp QUIT
QUIT:
xor eax, eax
ret
Само собой, в итоге
Поэтому не удивительно, что у Java лучший резлуьтат. Но этот результат относится только к данному тесту и очень мало что говорит о производительности в реальных задачах.
PS: 6 секунд у Java в этом теста — это фактически время на «прогрев». Наверняка если размер одного из циклов увеличить в 10 раз, то не получится 60 секунд, а много меньше.
Я приведу относительные значения:
C/C++ MSVC/Windows - 1.00
C/C++ GCC/Ubuntu - 1.00
C# (.Net 4.61/Windows) - 1.22
C# (.Net Core/Ubuntu) - 1.50
Java 8 (Oracle/Windows) - 1.56
Java 8 (Oracle/Ubuntu) - 1.56
JavaScript (Edge 14.14393/Windows) - 1.27
JavaScript (Chrome 54/Windows) - 4.60
<button onclick="javascript: benchmark();">Run</button>
<div id="output"></div>
<script type="text/javascript">
function benchmark() {
const t0 = new Date();
let i_counter = 0;
let i_loop1 = 0;
let i_loop2 = 0;
let i_loop3 = 0;
for (i_loop1 = 0; i_loop1 < 10; i_loop1++) {
for (i_loop2 = 0; i_loop2 < 32000; i_loop2++) {
for (i_loop3 = 0; i_loop3 < 32000; i_loop3++) {
i_counter++;
if (i_counter > 50) {
i_counter = 0;
}
}
// If you want to test how the compiler optimizes that, remove the comment
//i_counter = 0;
}
}
const t1 = new Date();
// This is another trick to avoid compiler's optimization. To use the var somewhere
println("Counter: " + i_counter);
println("Elapsed time: " + (t1.valueOf() - t0.valueOf()) + " ms");
}
function println(s) {
const element = document.getElementById("output");
var para = document.createElement("div");
para.textContent = s;
element.appendChild(para);
}
</script>
Haskell. Он ведь на пике популярности.
Ох как толсто…
Серебряной пули не существует, по простой причине что люди — разные, как и ЯП.
Поэтому какой яп изучать первым это уже личное предпочтение, новичка только можно ознакомить с возможностями определенных яп области, в которую он хочет погрузиться.
Первый язык, который стоит выучить, это, однозначно, C/C++.
Зная С++ вы не только за недельку другую освоите JavsScript, но и сможете покопаться в его движке и узнать все его секреты.
Зная С++ вы так же довольно легко сможете изучить любой другой язык, который там сейчас в моде, и при этом будете специалистом более высокого класса.
Не тратьте свое время на JavaScript, начинайте с базовых языков.
Я учился на Pascal. Синтаксис C казался непонятным, потому что там мало слов и много хитрых скобочек. Если бы мне в тот момент кто-то показал C++, я бы испугался, подумал, что это ужас-ужас-как-сложно и сбежал бы из этой темы. Возможно, навсегда.
У JS есть одно неоспоримое преимущество: она имеет мощнейший среди всех UI, установленный абсолютно на ккаждом компьютере. Остальные плюсы-минусы для новичка малозначительны.
Как С++-ник с некоторым стажем, категорически с вами не согласен. С++ — просто рассадник костылей и всяческих неочевидностей. Половина его 1600-страничного (на данный момент) стандарта — либо Undefined Behavior, либо Implementation Defined. Утрирую конечно, но впечатление иногда именно такое. А с инструментарием "из коробки" вообще печаль-беда.
В универе 5 лет писал лабы на C++ и не знал ни про какие undefined behaviors) А потом когда узнал, решил, что ну его нафиг все это изучать, и занялся веб-программированием.
Это я к тому, что для обучения необязательно лезть в дебри промышленного применения языка. Int/float, строки, управление памятью, классы с наследованием — этого достаточно для получения уверенных навыков. Потом можно переходить на что-то другое. Так что считаю C++ нормальным вариантом для первого языка.
Увы, никогда не знаешь из какой норы вылезет хорёк и грызанёт за пятку.
Я бесспорно уважаю С++. Но он становится всё более и более монструозен. Причём бестолково монструозен. В 17-м стандарте вы сможете использовать зета-функцию Римана и другой матан. Но по-прежнему будете выписывать типы итераторов руками — потому что все ждут Благословенных Рейнджей. Пренебрежительность тут не к самому предложению, которое считаю отличным, а к тому, что если его примут к 20-му — я ооочень сильно удивлюсь. Или втянете Буст, который размером со среднего слонопотама — и практически не подлежит декомпозиции.
В общем давайте закончим. Не хочу разводить очередной холивар.
А кто то до сих пор пишет типы итераторов руками вместо auto, пользуясь 17-ым стандартом?
При чём auto к итераторам для кастомных коллекций или любым трансформациям последовательностей?
Чем больше перекладываешь на компилятор, тем больше вероятность, что он тебя неверно поймет, а потом выкинет страшную длинную ошибку с несовместимостью придуманных им же типов.
Уж лучше я напишу
vector::const_iterator руками.
В универе 5 лет писал лабы на C++ и не знал ни про какие undefined behaviors)Лабы можно вообще писать на чём угодно, хоть на FORTRANе. А вот как только начинаешь писать что-то мало-мальски серьёзное — так UB и начинает «кусаться». А поскольку список UB — это не то, про что должен знать разработчик компилятора, а то, что должен знать каждый программист (иначе он не сможет их избегать), то да — для обучения C++ не очень-то годится…
Речь идет о языке для обучения, а не для написания чего-то мало-мальски серьезного. При обучении нет программ, которые идут в продакшн. Лаба либо работает, либо нет, это заметно сразу. Тем более что с оптимизацией никто не заморачивается, и программа разрабатывается и компилируется в debug-режиме. Для обучения условиям, циклам и целочисленным вычислениям C++ вполне подходит.
В каждом языке есть свои особенности, которые должен знать каждый программист, и которые новичок не знает. Это не значит, что новичкам ни один язык не подходит.
Речь идет о языке для обучения, а не для написания чего-то мало-мальски серьезного.Погодите — а в какой момент «обученный» таким образом программист сможет писать что-то серьёзное?
Если вы используете для обучения «обучающий язык» (неважно — Pascal или Logo), то всё просто: пока вы обучаетесь — вам неважно что там с UB происходит, начнёте работать — изучите всё, что нужно в рамках изучения C++.
А если вы сразу на C++ ваши лабы пишите — то как и в какой момент вы научитесь не использовать «по ошибке» UB?
В каждом языке есть свои особенности, которые должен знать каждый программист, и которые новичок не знает. Это не значит, что новичкам ни один язык не подходит.Почему же. Им подходит любой язык в котором подобные особенности встречаются достаточно редко при написании реальных программ. C++ к ним, увы, не относится.
Погодите — а в какой момент «обученный» таким образом программист сможет писать что-то серьёзное?
Переход к серьезным проектам начнется в тот момент, когда он "обучится" и начнет пробовать писать что-то сам.
Если вы используете для обучения «обучающий язык» (неважно — Pascal или Logo), то всё просто: пока вы обучаетесь — вам неважно что там с UB происходит, начнёте работать — изучите всё, что нужно в рамках изучения C++.
То есть, учился он на Паскале, потом приходит к работодателю и говорит "Я на C++ не писал, что такое UB не знаю, возьмите меня на работу, я все изучу честно-честно".
А если вы сразу на C++ ваши лабы пишите — то как и в какой момент вы научитесь не использовать «по ошибке» UB?
Когда освоюсь с основами составления программ и начну писать более серьезные проекты, искать информацию о том, как что-то сделать самому, пытаться устроиться на работу в коллектив к другим программистам и т.д. Вариантов много, но для каждого надо уже уметь написать что-то на языке.
Undefined behavior конкретного языка это не то, что нужно знать при обучении основам программирования, которые от языка не зависят.
Таких — отрывают с руками. Как правило на работу идёт человек, который и одного языка толком не знает, но знает достаточно, чтобы приносить какую-то пользу.
Если десктопное приложение, то почему бы и нет. Да если даже Pascal, SQL, Prolog и Lisp. Без знания C++ его на работу с C++ никто не возьмет. Значит он должен изучить его при обучении. А чтобы устранять UB в конструкциях языка, надо сначала научиться их составлять. И здесь нет большой разницы, писать
Function f(a: integer, b: integer): integer;
f := a + b;
End;или
int f(int a, int b)
{
return a + b;
}
Зная С++ вы не только за недельку другую освоите JavaScript, но и сможете покопаться в его движке и узнать все его секреты.
Умея управлять космическим кораблём вы не только за недельку-другую освоите радиоуправляемый вертолёт, но и сможете покопаться в его движке и узнать все его секреты. Вперёд, на симулятор Союза ТМА!
JS хорош для образования тем, что он мультипарадигмален — на нем можно изучить и ООП и функциональщину.
Никогда не забуду лицо своего товарища, изучавшего С++ в универе, когда я впервые показал ему функцию высшего порядка.
template<typename In>
auto twice(In x, int arg) {
return [=] {
x(arg);
x(arg);
};
}— Не-не-не, Дэвид Блейн, это же шаблоны, как я это в библиотеку скомпилирую?
std::function<void()> twice(std::function<void(int)> x, int arg) {
return [=] {
x(arg);
x(arg);
};
}Много чего плохо в C++, но с функциями высшего порядка вроде ОК :)
Зная С++
Хорошая шутка.
В экосистеме JavaScript имеются несколько инструментов для разработки полноценных мобильных приложений
С морем костылей и велосипедов изнутри
Я, кстати, не ратую за JavaScript только потому, что обучаю на нём программировать. Всё, как раз, наоборот. Я обучаю этому языку именно потому что знание JavaScript – это верная дорога к первой работе программиста.И больше ничего, кроме JS, после этого заявления, в статье не оказалось. Слишком сильный упор на JS, я бы не хотел начинать с него, когда вижу, что на нём частенько пишут…
Я не в коем не агитирую брать JS как единственный подходящий для обучения язык, но вот если меня спросят, что учить, чтобы попасть в it, то я скажу веб, т.к. за другие сферы я не могу судить и сказать человеку что-то вроде: «когда начнет получатся, то работа найдеться.».
О всяких языках не имеющих практического применения в наше время я вообще говорить не буду, т.к. только если ты студент, то можешь себе позволить потратить время на изучение «мертвого» языка для крепкого освоения основ, а у студента как бы и выбора не будет между языками, ему что сказут учить, то он и будет учить.
У людей с первых минут трудности с формализацией задачи на естественном языке, с понятием «переменная», с линейностью программы (ну, как так получается, что раньше исполняется то, что выше? почему так?). Госспаде, да они больше тушуются, пытаясь английские буквы на клавиатуре найти, а уж Home, End и Enter при них нажмешь — и ступор. И среда разработки, которая что-то там подсказывает (исходя из исходного кода с опечатками и ошибками), и это ни в какие ворота не лезет.
Веду лабы по программированию уже лет 5, в качестве языка С. Такой же опыт. В 80% перехожить собственно к написанию программы рано, т.к. не могут решить задачу в голове и формализовать ее.
Из последнего: самые первая лаба, нужно просто написать линейную программу, разлочить сумму на наминал + кол-во. Что может быть проще, но студент впадает в ступор. Спрашиваю его самого, сколько и чего надо, отвечает. На вопрос как он это посчитал, ступор.
В принципе стараюсь донести до них не знание конкретного языка, а в целом понимание того как составлять программу, т.к. язык как уже 100500 раз писали учится за пару месяцев. Читать его можно после беглого прочтения документации и усвоения базовых конструкций.
На эту тему хорошо говорит один из авторов Agile манифеста «Uncle» Bob Martin. Рекомендую его лекцию «The Future of Programming».
Одно дело показать человеку который не планирует зарабатывать на жизнь программированием как облечать себе жизнь простыми скриптами, или как настроить свою веб-страницу ( тут любой питон или js подойдут ), и совсем другое учить будущих программистов. Во втором случае я уверен, что необходимо начинать с языка который не прячет управление памятью, а напротив дает программисту полный контроль над программой. Черные ящики конечно штуки хорошие, но я считаю что человек должен разбираться в инструментах которыми он пользуется.
А теперь сравните этот старт с C#, Microsoft предлагает бесплатное IDE, идеальное для разработки. Понятное и простое поведение this, сложность может возникнуть разве что с пониманием ссылочных и значимых типов. Если нужен интерфейс, то в той же IDE есть визуальный инструмент для его создания.
У меня создалось такое впечатление, что автор статьи ни разу не пытался никого научить программированию и из-за этого оторван от реальности. Сразу вспоминается смешная картинка с кривой обучения. Если хотите кого-то отговорить изучать программирование, то лучше JavaScript'a будет, наверное, только Lisp или Brainfuck.
Определенные диалекты Lisp получше JavaScript будут. Совершенно несправедливо записали вы его в один ряд с Brainfuck.
Вы совершенно неверно ассоциируете Lisp с чем то древним. Возьмем диалект Clojure, современный и активно развивающийся диалект lisp под JVM, за него могу сказать что он намного проще чем JavaScript и стартануть с него в современную фронтенд веб-разработку на ClojureScript намного проще чем скажем с ворохом js либ в виде react+redux+babel+webpack+lodash+npm+nodejs
Спасибо, с уважением.
Теперь я хочу написать что-то минимально полезное с интерфейсом
в HTML/css, чтобы получить консольный или нормальный интерфейс.
Так вы хотите или не хотите написать что-то с интерфейсом?
А теперь сравните этот старт с C#, Microsoft предлагает бесплатное IDE
Класс, то есть написать пару строчек в любом текстовом редакторе, сложнее чем установить всю эту громадину от MS? Не говоря уже, о разработке на любой операционной системе кроме Windows.
1) Мало кому нравится писать консольные программы и радоваться их исполнению, особенно на старте изучения программирования, и стоит отметить, что радость очень хороший мотиватор. Но ознакомление с синтаксисом лучше начинать с консольного hello world в четыре строки, чем с целой мешанины html и js.
2) Судя по данным Net Applications доля linux 2%, доля Macos 10%, т.е. в 88% случаев windows уже стоит. А установить Visual Studio гораздо проще, чем пытаться понять почему страничка написанная в блокноте работает, но подключить библиотеку из js файла не получается. Ах да, надо установить IDE для разработки, ой, в случае с JS ещё надо найти бесплатную, а ещё надо её настроить, если вдруг всё не настроено по умолчанию.
В общем хотел бы я посмотреть на таких самоучек, которые решать начать с JS.
Да, только эти 10% + 2% как раз и есть программисты.)
А установить Visual Studio гораздо проще, чем пытаться понять почему страничка написанная в блокноте работает, но подключить библиотеку из js файла не получается.
Серьёзно? Установить VIsual Studio + разобраться в синтаксисе C#, построить UI (а мы же говорим именно про него) легче чем подключить js файл к html?
Ах да, надо установить IDE для разработки, ой, в случае с JS ещё надо найти бесплатную, а ещё надо её настроить, если вдруг всё не настроено по умолчанию.
Ну Вы или намеренно лукавите, или не знаю. В отличии от C#, для JS никакая IDE ненужна. Как раз это я и написал вам. Я честно говоря только одну платную IDE для JS — WebStorm, да и 90% людей используют Sublime/Vim/Notepad++
Да, только эти 10% + 2% как раз и есть программисты.)
Т.е. я уже не программист? И тот, кто хочет стать программистом, сразу устанавливает себе Linux или бежит покупать Mac, только потом начинает изучение?
Серьёзно? Установить VIsual Studio + разобраться в синтаксисе C#, построить UI (а мы же говорим именно про него) легче чем подключить js файл к html?
т.е. при изучении JS в синтаксисе разбираться не надо? И да, в Visual Studio легче построить интерфейс и навесить на него обработчики нажатий, чем сделать то же самое в JS+HTML.
В отличии от C#, для JS никакая IDE ненужна.
Да что вы говорите? Откройте в хроме index.html с подключенной js. Что вы увидите? Что JS не загрузился из-за ограничений безопасности, оказывается нужно запускать хотя бы на локальном сервере, который в Webstorm работает сам по себе, а в перечисленных вами редакторах надо настраивать, о чем я и написал.
Хотя бы потому что для того чтобы писать на JS нужно понимать браузер, сервер, хтмл и много других сложных по своей сути вещей. Работал с веб приложением один раз — мне джаваскриптист сказал: выгрузи на сервер сам, я занят — так я целый день убил.
Другой пример — с тем же c++. Когда начинал с ним работать, нормальную визуальную среду разработки с графикой и прочим, которая работала бы с нужной мне программой я искал месяц. Ещё месяц конфигурацию рнастраивал. Если бы я учился на программиста в университете и спрашивал бы у уже знающих, тогда да. Но самоучке которому не кого спросить с c и c++ начинать — это очень сложно.
Мне подошёл паскаль как первый язык, потом в университете делфи со средой разработки и всё отлично, пото и на питон, и на с#, и на с++ переход безболезненный (на с++ — почти безболезненный… боль доставляет только компилятор, который делает то что хочет он, а не то что предписывают инструкции).
Мне джаваскриптист сказал: выгрузи на сервер сам, я занят — так я целый день убил.А причём тут JavaScript? У нас задача «выгрузить в прод» может и неделю занять, хотя никакого JavaScript'а мы не касаемся.
компилятор, который делает то что хочет он, а не то что предписывают инструкцииИзвините, но когда компилятор делает не то, что продписывают инструкции/спецификации (ISO/IEC 14882, POSIX и прочие) — то это ошибка и за это нужно «бить по рукам»^H^H^H^H^H заводить багрепорты.
Microsoft предлагает бесплатное IDE, идеальное для разработки.
Ни в коем случае не критикую ничьи программные продукты, но так перехвалить ни один не могу )
Я бы наоборот наверное, сейчас бы пробовал первым учить как раз Lisp (Scheme, почему бы и нет?), хотя бы до уровня "умею решать алгоритмические задачки".
Наиболее подходящими для обучения программированию языками считаю Python и C#.
register_globals, словаремассивы, написание кода прямо внутри верстки.Как в восточных боевых искусствах, путь к совершенству в программировании начинается со смирения. У начинающего кодера много гордости и энтузиазма. Ради свободы самовыражения он готов за сигнатурой каждого метода лезть в интернет, тратя время и полагаясь на не всегда актуальные мануалы. И только когда человек признает, что поддерживаемость кода важнее количества сэкономленных символов, что компилятор умнее его и все ограничения взяты не с потолка, начинается его становление как профессионала.
Для обучения C# лучше всего использовать в связке с LINQPad, а не с Visual Studio. Там можно сразу запускать простые примеры, не загружая новичку голову структурой проекта, классами и пространствами имён.
Я полностью согласен, что при наличии знаний\опыта\таланта можно достигать впечатляющих результатов с помощью любого инструмента. Точно так же я не спорю с тем, что в любой технологии есть свои недостатки. Но оба этих утверждения — чистой воды демагогия, потому что всегда можно сравнить два инструмента и определить, какой из них для конкретной задачи подходит больше. В данном же случае PHP, при всех его плюсах и возможностях, объективно проигрывает Питону и Шарпу по пригодности для обучения.
Можете несколько доводов в его сторону, может будет мне причина хотябы поверхностно его изучить для расширения кругозора.
Если Вы хотите ознакомиться с полноценным ООП, посмотрите Smalltalk/Pharo.
Да вроде наличие полноценного ООП никогда не было критерием популярности языка… Когда прочитаете "Pharo by example" поймёте, что ООП в полноценном виде ни в одном мейнстрим языке нет в наличии. Чаще всего мы имеем банальное процедурное программирование с классами, ну и, благодаря исторической роли C++, это принято ассоциировать с ООП.
В JavaScript действительно не самая плохая поддержка ООП, но есть существенные минусы:
- нет сокрытия данных (можно напрямую обращаться к полям объекта без посылки сообщений)
- в прототипный подход активно внедряют классы, что приводит к дикой мешанине
Так же его нельзя назвать объектно-ориентированным языком, т.к.
- не всё является объектами
- не все действия возможно выполнить через посылку сообщений объектам (из тривиального: операторы не являются методами)
нет сокрытия данных (можно напрямую обращаться к полям объекта без посылки сообщений)
Сокрытие данных есть.
function makeObject() {
var b;
var self = {};
self.getB = function() { return b;};
return self;
}
var obj = makeObject();
var newB = obj.getB();Вот так как-то.
Можно сделать != есть.
Можно сделать в любом языке, но по умолчанию и повсеместно — не везде есть.
Во-первых не в любом языке можно это сделать.
Во-вторых, равно можно сделать фактическому наличию фичи или нет — определяется усилиями, которые нужно предпринять, чтобы использовать фичу. Тут усилия, как несложно убедиться — минимальны. Их нужно не больше,
чем для того, чтобы написать private в какой-нибудь Джаве.
Во-первых не в любом языке можно это сделать.
А в каком нельзя?
Тут усилия, как несложно убедиться — минимальны.
Ага, всего лишь переключиться с объектного подхода на функциональный и использовать замыкание вместо метода.
Если это считать минимальными усилиями для поддержки сокрытия данных, то можно и чистый С назвать объектно-ориентированным :-)
А в каком нельзя?
В php третьем нельзя было, насколько я помню.
Ага, всего лишь переключиться с объектного подхода на функциональный и использовать замыкание вместо метода.
Нет тут никакого переключения подходов. Есть объект, у него есть методы, с их помощью можно попросить объект что-то сделать. Сборка объекта только происходит немного не так, как вы привыкли, вот и всё.
Если это считать минимальными усилиями для поддержки сокрытия данных, то можно и чистый С назвать объектно-ориентированным :-)
Объектно ориентированное программирование можно осуществлять на разных языках, только с разными усилиями. В случае с javascript — усилия для сокрытия переменных — минимальны. Насчёт Си — не знаю, не пробовал.
В php третьем нельзя было, насколько я помню.
Не знаю, не застал эту версию… но думаю, что варианты были даже там.
Нет тут никакого переключения подходов.
Ну как же нет… Вы даже не замечаете, что замыкание использовали?
Если вдруг встретите способ сделать закрытые переменне в третьем php напишите — я в своё время так и не понял как. Но, думаю, то примеров языков, где это сделать нельзя ещё не один и не два.
Что касается замыкания — да, использовано замыкание, для того, чтобы реализовать определённый аспект ООП. Подход как был объектно ориентированным, так и остался.
Не думаю, что я буду заниматься археологическими исследованиями PHP )))
Просто ещё раз подчеркну, на мой взгляд, принципиальный момент — чтобы назвать язык объектно-ориентированным мало иметь возможность обеспечить сокрытие данных в объекте, нужна невозможность создания объекта без такого сокрытия.
Ну а подход, его можно и в чисто функциональных языках спокойно применять, но там хоть есть чёткое осознание что и зачем. В JS же такая смесь парадигм, которая не позволяет их как-то разграничить.
Просто ещё раз подчеркну, на мой взгляд, принципиальный момент — чтобы назвать язык объектно-ориентированным мало иметь возможность обеспечить сокрытие данных в объекте, нужна невозможность создания объекта без такого сокрытия.
Покажите, какая конкретно часть парадигмы ООП вообще требует возможность скрывать поля? Инкапсуляция вообще не про это, она про то, что методы взаимодействия с данными идут рядом с самими данными, но вовсе не требует ограничения доступа.
Насколько мне известно, никакая. Язык вообще не обязан скрывать данные, чтобы назваться полноценным ООП. Возможно, наоборот: чтобы быть ООП в первоначальном смысле этого слова, язык не должен скрывать никакие поля. ООП пытается моделировать реальный мир, и расскажите, пожалуйста, например, какие поля у объекта класса "трактор" "скрыты разработчиком" для прочтения "методами" объекта класса "человек"?
Покажите, какая конкретно часть парадигмы ООП вообще требует возможность скрывать поля?
Ну смотрите, объект по определению может иметь состояние и может отвечать на сообщения и всё, больше ничего он не может.
An object can do exactly three things:
- Hold state (references to other objects).
- Receive a message from itself or another object.
- In the course of processing a message, send messages to itself or another object.
Соответственно, доступ к состоянию возможен исключительно через посылку сообщения.
Если мы вводим какой-то иной способ доступа к состоянию мимо сообщений, то это что-то что к ООП уже не относится.
принципиальный момент — чтобы назвать язык объектно-ориентированным мало иметь возможность обеспечить сокрытие данных в объекте, нужна невозможность создания объекта без такого сокрытия.
Вы только что сказали, что java, c#, c++ и многие другие языки — не объектно ориентированны :).
Но напоминаю, что я просто хотел сказать, что на javascript можно делать закрытые поля.
Вы только что сказали, что java, c#, c++ и многие другие языки — не объектно ориентированны :).
Ну, почти. Не совсем объектно-ориентированы, или не объектно-ориентированы в первоначальном смысле. Парадигме свойственно эволюционировать. Тем не менее, требования обязательного ограничения доступа в ООП нет и в современном понимании.
Вы только что сказали, что java, c#, c++ и многие другие языки — не объектно ориентированны :).
Да это давно уже не новость. Большая часть мейнстрима — процедурные языки с элементами ООП.
Большая часть мейнстрима — процедурные языки с элементами ООП.
И, собственно, если исходить из вашего определения — нету большой разницы между поддержкой ООП в javascript и в java, C++ и php.
Неверное понимание. И то, и другое является ООП. Никто не говорил, что это может быть сделано только одним способом, и то, что мы видим javascript, java, python и tcloop с совершенно разными подходами — иллюстрация того, насколько разными могут быть разные подходы.
Неверное понимание. И то, и другое является ООП
Собственно я и хотел сказать, что Source неверно понимает тему. И особенно хорошо это понятно, если продемонстрировать что следует из его рассуждений.
Хорошо, что теперь и Вам понятно, что в Java нет нормального ООП :-)
Скажите пожалуйста, как можно было из моих слов
Собственно я и хотел сказать, что Source неверно понимает тему.
Можно было сделать вывод, что мне понятно, что в Java нет нормального ООП?
Но вообще интересно, в каком языке нормальное ООП есть?
Это была ответная шутка :-)
Но вообще интересно, в каком языке нормальное ООП есть?
ООП на базе классов — Smalltalk
ООП на базе прототипов — Self
А вообще дело, конечно, не в "нормальности"… а в чистоте парадигмы.
Концепция обязана быть сформулирована предельно конкретно и настолько коротко, насколько возможно… иначе Вы просто будете растекаться мыслью по древу на каждом шагу, подгоняя под неё что угодно.
Двумя комментариями ниже я привёл определение ООП в 3-х коротких предложениях. А теперь попробуйте сформулировать определение ООП так, чтобы оно в полной мере описывало то, что понимается в C++, Java, C# под этой аббревиатурой. Скорее всего, Вы с удивлением поймаете себя на использовании терминов, которые относятся к программированию в целом, а не конкретно к ООП, типа абстракция, полиморфизм и т.д..
У нас с вами получается, что ООП это одно, а поддержка ООП это другое, что в общем, логично.
Я считаю, что, если язык позволяет писать программы, которые позволяют без существенных усилий следовать принципам ООП, но не энфорсит их, то его можно считать объектно ориентированным.
С этой точки зрения большинство мейнстрима всякого — объектно ориентировано.
У нас с вами получается, что ООП это одно, а поддержка ООП это другое, что в общем, логично.
В целом да. Нет ничего плохого в частичной поддержке какой бы то ни было парадигмы в языке. Плохо, что сами парадигмы замыливаются и начинают неверно пониматься. Так мы и скатываемся до понимания в стиле "если есть классы — то это ООП". Гораздо лучше, когда программист осознаёт где границы конкретной парадигмы и какие фичи его любимого языка выходят за эти границы.
чтобы назвать язык объектно-ориентированным мало иметь возможность обеспечить сокрытие данных в объекте, нужна невозможность создания объекта без такого сокрытия.
Нет такого в определениях ООП, нет запрета на получение состояния объекта извне.
Приведите определение ООП, из которого не следует такой запрет.
Из классического определения он явно вытекает:
- Everything is an object.
- Objects communicate by sending and receiving messages (in terms of objects).
- Objects have their own memory (in terms of objects).
Я не вижу ни 4. Objects own memory could be set to be inaccessible to other objects, ни в явном виде, ни в виде следствий из 1,2,3. Возможно, я что-то не понимаю, приведите, пожалуйста, логическую цепочку, как из трёх пунктов следует ограничение.
Из третьего пункта следует, что у объектов есть состояние. Из первого пункта — что кроме объектов в программе ничего нет, а из второго — что объекты общаются только через сообщения.
А теперь вопрос: как можно получить доступ к состоянию одного объекта из другого объекта, если они могут взаимодействовать исключительно через сообщения?
Возможно, посылая сообщение "получить значение поля такого-то"?
Это сообщение запрещено?
Сразу отмечу, нигде не сказано, что "реакция на сообщение должна быть непременно методом". В определении парадигмы нет слова "метод" и конкретизации, что такое "сообщение". Под сообщением вполне можно понимать и запрос или запись значения поля.
Возможно, посылая сообщение "получить значение поля такого-то"?
Именно. Фишка в том, что механизм посылки/приёмки сообщений должен быть един в рамках конкретного языка (иначе это уже будет N разных понятий, а не одно — сообщения). Как Вы правильно заметили, это необязательно вызов метода и для полной поддержки ООП наличие методов не требуется. Но в большинстве мейнстрим-языков отправка сообщения — это именно вызов метода.
Итак, парадимга ООП не требует наличия запрета доступа к полям или методам, а реализация такого запрета — это уже воля разработчиков конкретного ЯП, продиктованная их желанием сохранить язык "последовательным" или "единообразным", конкретным выбором реализации понятий "сообщение" и "собственная память объекта" и так далее. Ограничения в такой реализации появляются икусственно — как следствие конкретного дизайна языка.
И вполне возможно, кто-то мог оказаться способен сделать это достаточно удобно и без искусственных ограничений.
Pharo by example
Занятно, конечно.
И иерархия стандартных классов да, увесистая и куда более подробная, чем у прочего множества ЯП.
SmallTalk/Pharo — по сути такой себе конструктор языков.
Однако, на практике не так много тех, кто захотел бы унаследовать от Magnitude и создать конкурента Integer'у (и Boolean то!).
Оттого, множество ЯП (созданных позже SmallTalk'а) начинает иерархию классов с уже «готовых» «привычных» типов данных. Их оказалось достаточно для абсолютно подавляющего числа задач.
Инкапсуляции в python нет в принципе — но есть соглашение, как следует называть методы и атрибуты, которые разаработчик считает приватными, соответственно, нарушение приватности будет намеренным и на совести нарушающего
Python поддерживает множественное наследование, используя стандартную библиотеку, можно создавать абстрактные классы.
Полиморфизм можно реализовать внутри одного и того же метода в зависимости от типа аргумента.
А вот насчет доводов — почитайте Python Zen, лучше чем там — не скажешь. Если вкратце, то дизайн языка способствует написанию кода, который читается легко и понимается однозначно.
Что имеется ввиду под "обойти инкапсуляцию"? Как подход "данные и подпрограммы для их обработки всегда вместе" можно "обойти"?
Если вы имели ввиду доступ к полям, то да: в Пайтоне нет ограничения доступа. Т.е. есть в джаве приватные методы и поля, есть публичные, так вот приватные кто угодно дёргать не имеет права. В Пайтоне нет: все члены класса публичные, и это не "можно обойти" защиту, это так сознательно сделано.
Если уж на то пошло, как раз в джаве это "можно обойти", если постараться: пишем паблик морозов и вот вам приватный метод доступен извне, хоть и под другим именем.
Это всего лишь распространённое заблуждение.
Encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof:
- A language mechanism for restricting direct access to some of the object's components.
- A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.
Наиболее подходящими для обучения программированию языками считаю Python и C#.
Полностью согласен.
Хотя одним из моих первых языков был Pascal и я до сих пор считаю его замечательным выбором для, кхм, академического изучения, рекомендовать бы его всем и каждому по умолчанию я бы не стал.
Всё-таки в 2016 огромную ценность имеет:
1. Количество актуальных материалов, библиотек, вопросов на stackoverflow наконец
2. Возможность из коробки или с быстрой установкой пары либ сделать что-то клёвое (игру/графическую визуализацию/сайт). Python standart library/.NET с pip/nuget для этого идеальны
3. Продуманность, стабильность языков и экосистемы. Тут у py/c# всё в порядке, в отличие от… (не будем показывать пальцем).
Я бы добавил что эти две технологии равноценны во всём, кроме, пожалуй, структур данных. Их лучше изучать на C#. Алгоритмы же можно изучать и там и там.
Как первый язык, чтобы сделать что-то относительно полезное? Думаю, это вполне разумно.
UPD: Когда я начал писать комментарий, я думал, что он окажется третьим.
Замыкания, асинхронность, прототипное наследование, неявное приведение типов…
Видимо нарушает ваше эталонное мировосприятие навязанное другими языками?
Про генераторы в Python можно не рассказывать и всё будет хорошо. А вот не рассказывать про сложные приведения типов и вообще особенности композитных типов JS не получится.
херачишь какой-то непонятный маллок (забыл, как оно в паскале называется), чтобы сделать массив переменного размера.
всё гораздо проще
GetMem оно называется.
Тут есть ещё одно соображение: перед тем, как что-то автоматизировать, стоит разобраться, как это делать руками. Перед тем, как использовать калькулятор, научись складывать и умножать вручную, и хотя бы разберись, что же это такое — квадратный корень.
Если же взглянуть на данные по JavaScript, то окажется, что на одну вакансию приходится всего 0.6 программиста.
Я вижу на картинке 1.6.
Да, он устроен просто — но prototype-based наследование легко понять, когда у тебя уже есть изрядный опыт, а в начале обучения это может сломать мозг. То же — насчёт областей видимости и замыканий в JS.
По мне, так лучше бы начинать с какого-то языка, где всё устроено именно так, как кажется на первый взгляд. Правда, в голову приходит только покойный Паскаль…
лучше бы начинать с какого-то языка, где всё устроено именно так, как кажется на первый взгляд.
А знаете, тут вот шутят насчёт Haskell, и я тоже раньше думал, что это очень сложный язык. Но когда начал изучать, оказалось, что он весьма простой (основной косяк, что про него любят писать заумно, но это не вина языка). После освоения нескольких базовых концепций, всё остальное выстраивается на их основе, настолько естественно, что иногда диву даёшься… Чуть ли не любую библиотечную функцию можно переписать в пару строк, потом открыть код GHC и с удивлением обнаружить, что именно так она и реализована. Я более-менее знаю больше 10 языков, но ощущение "всё устроено именно так, как кажется на первый взгляд" у меня возникло впервые именно при изучении Haskell.
Не берусь пока его советовать в качестве первого языка, но в качестве одного из первых 5 ЯП однозначно рекомендую.
Вот результат опроса, который проводился на Stack Overflow в 2016-м году. В нём участвовало 49397 разработчиков. Более половины из них используют JavaScript.
В результате множество компаний нанимают JavaScript-разработчиков, но разработчиков этих не так уж и много.
Это 5. Я понимаю, что Вы всё подгоняете, чтобы каждый пункт был в пользу JavaScript, но можно же хоть как-то согласовано это было сделать.
P.S. Если по существу, то с JavaScript имеет смысл начинать тем, кто хочет заниматься разработкой фронтенда для веб-проектов в ближайшие 5 лет. Для остальных это не лучший выбор первого языка.
Берём Vaadin, пишем логику на java.
А чем вам, скажем, Clojurescript не угодил? Вот уж что точно не JS.
Еще вроде Scala и Kotlin компилируются в JS.
Я вот всё облизываюсь на этот интересный язык, да времени мало. А жаль.
Вот Вы хотите, чтобы ребенок научился кататься на велосипеде, скорее всего Вы ему купите вот это:
Ну или это:
А в качестве первого ЯП выбирать JavaScript, это:
Т.е. когда ты на таком умеешь — ты можешь ездить на любом другом, но начинать учиться надо точно не с него :)
да, если мы про джаваскрипт, то на последнем между педалями и колесом там стоит передача, разворачивающая направление вращения
И нет там никаких передач, вот пруф.
Но в юницикле (велосипеде-моноколесе) точно никаких передач нет и колесо там — круглое — знаю, катался, падал :)))
Или это шутка юмора была, про то, что JS еще сложней? Тогда каюсь — не понял :)
именно так
Как известно, сложность системы измеряется в wtf, так вот в велосипеде-моноколесе слишком мало wtf, чтобы его можно было сравнивать с js. Нужно было хоть что-то добавить :)
Серьёзно. Моноколесо я бы с C сравнил. Всё возможно, но и следить нужно за всем самому: память и указатели, строки и массивы, и так далее.
А JS — http://www.besportier.com/archives/world%E2%80%99s-largest-bike-didi-senft.jpg
С виду велосипед как велосипед, да и владелец катается на нем с лёгкостью. Проехать 20 метров за 100 рублей и выиграть 500 кажется плёвым делом. И первые два метра действительно думаешь, что всё в порядке. А дальше, абсолютно внезапно — лицо на асфальте и полное недоумение.
<script>
document.write("Hello, world!" + (3+5));
</script>
Замыканиями, прототипами, нестандартным и не явным приведением и много еще чем.
Поясню.
Замыкания, прототипы, вот эти все умные слова, которые вы (и не только вы) тут написали, появятся, когда
Что до приведения типов, соглашусь — оно создает много проблем новичкам. Но, слава богу, всегда есть решение, которые многие мои знакомые физики до сих пор испольуют: «сомневаешься — приводи явно».
А к моменту, когда человек начнет хоть чуть-чуть понимать, что он вообще пишет и как оно работает, можно будет выбрать второй язык. Осознанно. И вот вторым JS будет далеко не для всех.
Я — школьник, который умеет открывать блокнот и браузер. Что в браузере есть такая штука, как DevTools, я пока не знаю — этого гришка из 6 «Б» — известный в моих кругах эксперт в области IT — не показал.
Где прикажете читать ваше «Hello, world»?
Я даже в QBasic-е на IBM PC XT с видеоадаптером Hercules и монохромным режимом искал графический режим. И находил-таки!
Неужели, вы считаете, что ребенок, который сможет замутить клон «злых птиц» в браузере, станет изучать более сложный (и неочевидный) Node.js? До него еще дорасти надо!
Что касается консоли, то, конечно, ее умный ребенок быстро найдет. Но использовать станет разве что для логов.
Мне бы и в детстве браузер… эх…
document.write(prompt() + 1);Ой, а почему это тут 11 написано, а я хотел 2?
Приехали.
Если человек не сможет написать «Number» и скобочки, спросив у более опытного товарища, вряд ли ему суждено программировать.
Она даже мне, не новичку, не по зубам. Да, признаюсь, я время от времени наталкиваюсь на дебильное поведение, при котором, например, [ ] + [ ], [ ] + { }, { } + [ ] и { } + { } — все выдают разные результаты и даже различного типа.
А в примере со сложением проблема решается просто и элементарно: писать Number (или String) должно быть обязательно всегда, во всех случаях, если имеем конструкцию вида строка + число. То есть, вместо сложного приведения типов и неожиданного результата язык должен был выкинуть исключение. Соединяешь число со строкой — будь добр явно укажи, что ты и во что преобразовываешь.
А вот что действительно следовало бы запретить — это обратное неявное приведение. Строка не должна становиться числом, незаметно для программиста. Тогда и программист будет понимать разницу между 1+1 и '1'+'1'. И глупостей делать не будет.
Использовать + для конкатенации строк или массивов — это само по себе глупость, правда зачастую от создателей языка. В данном случае мономорфность операторов — благо даже для сильной типизации, а для слабой типизации — сущая необходимость.
Pascal — использует +
C — не использует, но в нем со строками вообще беда
Java — единственный в языке оператор, переопределенный для единственного класса — "+" для класса String. Ради него сломали стройный синтаксис.
C# — операторы переопределяются, "+" для строк включен
C++ — аналогично
Basic — по-разному, не помню уже… Кажется, там можно "+" или "."
JS — "+"
Python — "+"
Теперь скажите мне, какой мейнстримовый язык я пропустил.
А еще предложите свой, более очевидный способ конкатенации строк.
Мейнстрим-решения не всегда лучшие, зачастую что-то исторически сложилось, а потом все годами жуют кактус во имя обратной совместимости..
Есть вполне себе хорошие варианты:
"++" — Haskell, Erlang
"<>" — Elixir
".." — Lua
"." — Perl, PHP
Точки для конкатенации мне тоже не нравятся, т.к. вызывают лишние ассоциации с другими вещами, но всяко лучше, чем +.
Ну а ++ или <> вообще идеально. К сожалению, исторически сложилось, что ++ в С-семействе языков зарезервирован под инкремент.
Два символа вместо одного для самого популярного оператора?
Это конкатенация то самый популярный оператор? Для того, чтобы что-то вставить в строку в 90% случаев интерполяция используется… Теперь она даже в JS есть под названием "String Substitution".
> Чем разыменовывать-то указатели? Стрелочками? Два символа вместо одного для самого популярного оператора?
PS ну а касательно самой конкатенации — в той же java используется не то, чтобы реже других способов формирования строк.
irb(main):001:0> '1' + 1
TypeError: no implicit conversion of Fixnum into String
Неявные преобразования в строку запрещены. А это Ruby, где магии вагон и маленькая тележка.
Преобразования а строку можно запрещать, если есть простой и удобный toString для любого объекта. Как в Java. Думаю, в Ruby он есть.
Злостность манкипатчинга сложный вопрос, ActiveSupport, сплошной манкипатчинг по сути своей. Но народ не сильно жалуется, жалуется когда например какой-нибудь gem начинает неистово потихому расширять ActiveRecord, потом ищи концы из-за чего пошло не так.
Манкипатчинг пытались отрегулировать, добавили допонительную функциональность под это (не помню как называется), но так никто почти и не пользовался ей, поговаривают что поитогу выпилят обратно, вместе с continuation.
PS хотя в продакшене видел расширение NilClass, добавление к нему операций индексирования и еще пары часто употребимых. Видать надоело городить проверки, try является частью Rails, но в последних версиях добавили эквивалентную замену в std.
В корне не согласен со статьей… Ну зато у меня конкуренация на рынке труда будет меньше!
По моему мнению, язык программирования для детей должен уметь разговаривать и рисовать, а для этого нужно:
- работающую программу в одну строчку
- ввод и вывод текста
- графические примитивы — точка, линия, окружность, заливка контуров
А подросткам обязательно надо изучать основные алгоритмы и структуры данных, для чего надо дополнительно:
- строгую типизацию
- ООП
И я, право, не знаю, что подходит лучше, чем древний бейсик и древний паскаль. На каком современном языке программирования можно в 10 строчек нарисовать синее небо, зеленую землю и желтое солнце? Или звездную ночь? А я такие программы набивал с тетрадки в 3 классе, а в 5 писал сам.
Поддержу! Stratch, Logo и Racket для начального обучения самое то.
Кстати, Stratch в том числе хорошо решает проблему "поделиться результатом с друзьями".
Ещё очень круто выглядит Project Spark.
Они не имеют ничего общего с промышленными ЯП.
А значит — проблемы, которые будут возникать у «разработчиков» на этих языках, будут разительно отличаться от тех, которые возникают у настоящих разработчиков.
Рискуем получить целую когорту детей, которым нравится связывать блоки, но которым не охота (медленно, тупо, некрасиво, стопятсот причин) натыкивать буквами команды. И читать они их не умеют.
То есть вы поднимаете квалификацию ребенка (он уже может запрограммировать простую игру в Scratch), давая ему совершенно бесполезную технологию и, попутно, забивая ему голову ньюансами этой технологии.
Хотя, это всё требует осмысления, конечно…
Ну, если для Вас вся суть промышленного программирования сводится к "натыкивать буквами команды", тогда конечно )))
Во-первых, блоки только у Scratch. Во-вторых, это всяко веселее, чем блок-схемы на бумажке, которые мы в школе рисовали. В-третьих, вспомните, что было 10 лет назад, что есть сейчас и Вы поймёте, что никто не знает как будет выглядеть промышленное программирование ещё через 10 лет.
давая ему совершенно бесполезную технологию
Ох, я чувствую дай Вам волю, Вы и цветные карандаши у детей отберёте..
Школьная программа по информатике — кошмар. Была и остается. Я, слава богу, учился программировать не в классе информатики. И, кстати, мы изучали Паскаль. Просто, я всю программу по нему знал на момент начала курса, что мне абсолютно ничего не стоило.
>В-третьих, вспомните, что было 10 лет назад, что есть сейчас и Вы поймёте, что никто не знает как будет выглядеть промышленное программирование ещё через 10 лет.
10 лет назад я начал изучать C++. В данный момент я пишу на C++. Думаю, что он никуда не денется еще лет 10.
Javascript, кстати, тоже вряд ли куда-то исчезнет в ближайшее время. Просто, будет продолжать обрастать всякой пеной, но так мы же десь не о фреймворках спорим — их и для C++ вышла куча за 10 лет, и для Java…
>Ох, я чувствую дай Вам волю, Вы и цветные карандаши у детей отберёте…
Знаете, я полагаю, что если школьник начинает рисовать всерьез, то есть не просто учится срисовывать мультяшек с телевизора, но и хочет стать настоящим художником, ему нужно немедленно купить приличный графический планшет типа Wacom (разумеется, если седства позволяют).
Или, если ему нравится рисовать карандшами, то, как минимум, сканер — чтобы он мог своим творчеством делиться.
Хотя, сейчас чем раньше юный художник освоил планшет, тем раньше он начнет зарабатывать деньги любимым делом.
Хороший пример привели ;)
10 лет назад я начал изучать C++. В данный момент я пишу на C++. Думаю, что он никуда не денется еще лет 10.
Рад за Вас и даже могу допустить, что Вы всё на том же подмножестве C++ программируете, игнорируя вышедшие стандарты. Но если посмотреть на web, mobile, робототехнику, там произошли изменения гораздо масштабнее, чем в С++.
Ради web-разработки я вынужден был в свое время изучить Java, которая, в смысле парадигм и синтаксиса, ушла от C++ не сильно далеко. Android отличается от Windows в плане идеологии куда сильнее. Например, меня в свое время шокировало, что любое неактивное окошко в нем система может безжалостно прихлопнуть. Неделю ходил — восхищался таким уровнем оптимизации.
За робототехнику не скажу. Уже выше писал, что ЧПУ не занимался. А других роботов и вовсе не встречал.
А дикие скачки с JS-фреймворками, которые растут как грибы после дождя и так же быстро выходят из моды, я развитием не считаю, простите. Это — пена вокруг мейнстрима. Я только с год назад признал существование Node.js в принципе и немного начал в нем ковыряться. И сейчас, спустя несколько лет после его создания, он всё равно выглядит сырым, увы. Надеюсь, скоро и JS-сообщество успокоится и выработает уже парадигму для UI, люди решат, что хватит клепать фреймворки, а в Node.js доработают те досадные недоразумения, которые там случаются. Но будет это, думаю, не через год.
P.S. Или есть ещё какой-то Racket? 0_o
Я понятия не имел, что это такое — и просто решил, что что-то типа Scratch.
Racket я указал в том ряду как раз в качестве граф.планшета, уже не игрушечный, но всё ещё логичный и простой для понимания, с хорошей библиотекой, позволяющей детям не заскучать.
Но это — уже вкусовщина.
Это вопрос привычек. В принципе, чем меньше базовых концепций, тем проще язык.
В концепции единообразия типа:
- "Всё есть объект" (Smalltalk/Pharo)
- "Всё есть список" (Lisp/Scheme/Racket)
довольно легко въехать и легко ими пользоваться (если язык сам не нарушает свою концепцию на каждом шагу)
чем меньше базовых концепций, тем проще язык.
Проще для математика, но не для практика. Новичку изучать язык интересно не потому, что он красив внутри — там внутри любое ПэХаПэ может быть. Новичку инересно сразу получить работающий результат.
Сейчас по-моему уже для любого языка есть либо REPL, либо Playground, либо и то и то. Так что проблем с быстротой старта в первый результат никаких нет.
Для Java не подскажете?
Java Playground, Java REPL. Далеко не самые удобные, но хоть что-то…
В качестве первого языка, я бы Java не советовал.
Я бы тоже, но REPL ведь не только для поиграться бывает нужен.
Нормальный REPL обещают в Java 9. В общем, слоупочат с официальной поддержкой, как всегда.
И чем проще язык, тем проще получить работающий и понятный результат.
вот забавная книжица про Лисп вообще
http://landoflisp.com/
Нет, личного опыта на эту тему пока нет. Но из всех production-ready языков я только у Racket видел такую заботу о детях… Она по-моему красной нитью проходит через все обучающие материалы… Например, "How to Design Programs" начинается с написания программы управления ракетой, да и в целом просто замечальные библиотеки Teachpacks идут в составе стандартного дистрибутива. Помимо этого в него включен набор классических игр и руководство как написать свою.
Ну и "Realm of Racket" тоже конечно отличное дополнение.
Вот мы видим человека, который явно ЧПУ никогда в глаза не видел.
Это ваш JS не имеет ничего общего с промышленным программированием, в отличие от Лого.
Понятие «промышленное программирование» весьма многогранно, спорить о нем, сидя в разных концах — непродуктивно. Только зачем грубить?
Что до ЧПУ — тут вы меня подбили насмерть. Из «ЧПУ» я программировал только Ардуино. В планах было начать освоение ПЛИС-микросхем (это близко к моей теперешней теме), но пока я о них почти ничего не знаю. Разве только то, что даже там большинство людей предпочитают не тыкать блоки мышкой, а, всё же, писать команды.
Но мы же с вами тут обсуждаем человека, который до сих пор о программировании не слышал вообще, то есть, очевидно, ребенка или почти ребенка.
Вы уверены, что его обучение следует начинать с ЧПУ? Мозг не сломаете? Спрашиваю без подколки, на полном серьезе — я ответ не знаю.
Под ЧПУ я имел ввиду станок с компьютерным управлением. Конечно, не детская игрушка, а напротив очень опасная штука…
Ардуино, пожалуй, ближе, но тоже далеко.
Но вот Лого похож на вытачивание объекта на токарном станке, и я ни разу не слышал, чтобы эта черепашка, которая рисует линии на экране кому-то сломала мозг. Это язык простой и без лишнего, минимум абстракций. Научиться понятию аглоритм, последовательность, циклам — ну просто идеальный вариант. Во-вторых, результат не абстрактный, он нагляден, поскольку это картинка. Хорошо видно, где цикл недокрутили или перекрутили — это же просто кладезь багов, а тут вот оно, на картинке лишний поворот. Можно наблюдать процесс выполнения в "замедленном варианте" или пошагово и этот замедленный вариант тоже очень нагляден, поскольку чётко видно (именно видно) что за команда выполнилась и к чему это привело.
Ардуино ничуть к нему не близок. Си как Си — ничго особенного. Только памяти мало и адские лаги, если не оптимальный код написать.
Главная проблема всех «учителей программирования» (как с кавычками, так и без), как правило, состоит в том, что они пытаются преподавать программирование академически.
Они ставят последовательные задачи, цель которых — не получение результата, а оттачивание навыков само по себе.
А ребенку не интересно решать задачи. Ему интересно творить. Создавать продукт, черт возьми! В младших классах — впечатлять друга саморучно написанной игрушкой, в старшем — поразить девчонку фрактальной розочкой на день рождения.
Если бы меня в детстве учили программировать, я бы программистом не стал. Просто из вредности.
Ребенку надо дать инструмент, из которого ему по силам сварганить рабочий продукт в разумные сроки.
Поэтому, на мой взгляд, единственный вопрос, который имеет смысл поставить к языку программирования при выборе его в качестве академического — "за какое время на нем можно написать Сапер, Тетрис, или нарисовать фрактал Мандельброта?"
И, самое главное, — сколько строк кода для этого придется написать и насколько они будут сложны.
Для игрушек точно Scratch и Project Spark. Там можно гораздо интереснее вещи создавать, чем сапёр и тетрис. Для фракталов — Logo и Racket. И там и там, первый вариант — для маленьких, второй — для тех, кто повзрослее и хочет покруче.
Я вот, например, никогда не хотел брать чужие движки и наработки. Это же не программирование, а просто настройка чьей-то чужой сложной штуки. Это — не круто. Куда круче самому инициализировать графический режим (или создать OpenGL-окошко), самому на нем что-нибудь нарисовать…
А Scratch, как я уже сказал, в плане навыков настолько далек от обычного написания кода, что мне, разработчику с 10-летним стажем, приходится с ним разбираться дольше 15 минут.
Ну Вас не поймёшь, то Вы говорите, что для детей важно как можно скорее видеть результат, то предлагаете дать им голый OpenGL, где на рисование простенького треугольника можно пару дней угробить, если Вы через плечо диктовать не будете.
P.S. Современным детям нравится Minecraft, достаточно дать им удобную возможность автоматизировать тыкание в экран, чтобы привить тягу к программированию.
И вы предлагаете детям в самом начале пути подобное наставлять? Мол, не надо использовать наработки, сделанные до тебя, пиши велосипед по поводу и без. Не плохо было бы конкретизировать «детей» — есть разница между условным первоклассником и условным шестнадцатилетним ребёнком. Первому глубоко наплевать, как оно работает, лишь бы работало и было всё интерактивно, просто и легко. Второму уже следует объяснять, что программирование — это не те кулцхакеры из телевизора, которые усердно пингуют localhost, делая вид, что работают. Хороший программист, ИМХО, это не тот, который пишет движки по поводу и без, а тот, кто умеет использовать наработки (при этом различая плохие наработки от хороших), создавая из различных модулей, дополнений и расширений что-то уникальное. Естественно, если нет наработок — нужно самому делать, но в 99% случаев наработка будет или её нужно будет несильно доработать. Представьте себе веб-разработчика, который под каждый сайт (интернет-магазин, корпоративный сайт, витрина, блог) будет бабахать по движку собственного производства — мало того, что он потратит в сотни раз больше времени, чем оно того на самом деле стоило, так ещё и максимально усложнит поддержку продукта. Я уже молчу про то, что в плане безопасности это будет решето.
Младших, так сказать, детей, совершенно необязательно обучать промышленным ЯП, иначе учите ребёнка сразу управлять самолетом, а то чего он с велика своего начинает. Когда ребёнок растёт и если он проявляет интерес к программированию (даже «детскому»), тогда можно вводить его в «реальное» программирование. Не зря ведь есть детские велосипеды — дети немного отличаются от взрослых, и хоть ребёнка можно научить кататься на взрослом велосипеде (если он физически сможет его осилить), это вовсе не значит, что так оно и должно быть.
scratch, logo — вот это вот
Тут по-моему есть дилемма: императивному программированию проще обучать (с позиции преподавателя), а объектно-ориентированное проще понимать (когда ты чистый лист и никогда не программировал).
ООП в моём личном опыте — как велосипед: не получалось, не получалось, потом щёлк — получилось. Поехал. И прогу с ходу сразу запроектировал ООП, и потом несколько раз убеждался, что вышло по канонам.
На каком современном языке программирования можно в 10 строчек нарисовать синее небо, зеленую землю и желтое солнце? Или звездную ночь? А я такие программы набивал с тетрадки в 3 классе, а в 5 писал сам.
Повезло вам, у нас в школе мониторы были монохромные, так что мы могли нарисовать только зимнюю ночь.
По моему мнению, язык программирования для детей должен уметь разговаривать и рисовать, а для этого нужно:
работающую программу в одну строчку
ввод и вывод текста
графические примитивы — точка, линия, окружность, заливка контуров
В точку! Давно ищу что-то такое чтоб сделать программирование интересным для сына.
Scratch мы уже выучили и переросли. Хочется что-то более ориентированное на вычисления и работу с массивами, чтоб изучать программирование на реальных задачах из школьной программы. Думаю зайти со стороны геометрии, например чтоб ребёнок понял что такое синусы/косинусы. Не сухое определение про отношение длины катета к гипотенузе, а именно чтоб почувствовал что это такое. Например нарисовать с ним модель солнечной системы, чтоб вокруг Солнца крутилась Земля, а вокруг неё — Луна. Так школьник сам почувствует что тригонометрические функции повторяются с периодом 360 градусов, что |sin| <= 1, и т.д.
Python вроде хорош, но пока не нашёл подходящую библиотеку для рисования. Turtle-графика слишком примитивна и подходит только для узкого класса задач. Сам я Python не знаю, думал заодно выучить его вместе с ребёнком. Гугль выдал ссылки на Pygame, но как-то он мне не нравится. Последняя версия 2009 года, программа должна содержать цикл обработки сообщений, буферизация вывода на экран вызовами flip… как-то слишком сложно для первого языка. Хочется сразу рисовать по координатам линии и окружности, заливать цветом. Без необходимости писать ещё 10 малопонятных строчек потому что «тут так надо делать».
Смотрел и в сторону JavaScript. Из плюсов — web и возможность показать своё творение одноклассникам или учителю. Большой минус (для обучения) — асинхронность. Когда в других языках скорость анимации регулируется расстановкой delay — просто и понятно, в JavaScript приходится паковать код в функции и вызывать их по определённым правилам. Для ребёнка среднего школьного возраста это неоправданная сложность.
В общем я пока в поиске, надеюсь на «помощь зала» в этом топике.
Посмотрите Racket. Там есть и заготовки графики для игр, возможность вставить картинку в код и работать с ней как с константой, и рисование графическими примитивами.
А когда с рисованием наиграется, можно будет и примеры из SICP поразбирать.
Вот сама библиотека: http://mcsp.wartburg.edu/zelle/python/graphics.py
Вот документация: http://anh.cs.luc.edu/python/hands-on/3.1/handsonHtml/graphics.html
На каком современном языке программирования можно в 10 строчек нарисовать синее небо, зеленую землю и желтое солнце?
На Haskell.
Я, например, в 7 лет писал в DOS-овских bat-файлах последовательность вывода на экран чего-то, отдаленно напоминающего интерфейс (очень крутой и красивый!) программы-антивируса AIDSTEST. Дело было в 1993 году, я сидел за списанной IBM PC XT.
Ассемблер я, увы, так и не осилил. QBasic -> Pascal -> Delphi -> C++ -> C# -> Java ->…
Я, конечно, не элита, но, думаю, если бы у меня был ассемблер, знакомство с программированием пришлось бы отложить на несколько лет. По причинам, связанным с интеллектуальным развитием.
QBasic -> Pascal -> Delphi -> C/C++ -> Asm -> HTML+JS…
Ну т.е. от простого к сложному и пониманию как работает ПК, а потом снова в упрощение. Ну и параллельно «опускался» до схемотехники =)
Мы с вами, разумеется, никакая не элита. Элита начинала с ассемблера, потому что ничего другого не было. А самый топ элиты вообще обходился без транслятора и начинал программирование непосредственно с машинных кодов.
Правильнее будет выбрать направление/нишу и использовать нужный инструмент(язык). А то получается, что выбирается язык программирования, ради языка программирования, а не достижения определённых целей сего мероприятия.
Т.е. если человек хочет работать с вебом, а ему говорят — первым языком должен быт C/C++, ты должен знать основы аппаратной части, работа с процессором и т.д. В итоге, человек тратит год, а то и несколько лет на всё это, а к цели никак не приближается. А потом наконец берёт, изучает JS и получает сразу первые результаты.
IT технологии и так быстро развиваются, нужно сразу брать и изучать нужный инструмент, а не не язык программирования в вакууме. А то это будет, как обучение программированию в вузе(90% вузов такие), пройдёт несколько лет, а толку почти никакого. Даже на джуниора тянуть не будешь.
Например, собираешься делать сайты на JS, то и надо изучать сразу JS, а не C/C++. Вот к чему я клоню. Нужно выбирать язык для достижения целей. А то вчера был популярен Python, сегодня JS, завтра ещё что-то. Не значит, что нужно браться именно за какой-то из них.
Глупые на форумах — обычно по тому, что не изучают теорию и/или сам язык, а сразу начинают работать с фрамеворком.
игру, ос, приложение которое помогает тебе делать что-то, сделать открыточку (пару раз видел) — это да. А вот делать сайты люди не хотят, в особенности дети.
Я, как и многие из присутствующих, начал с дедушки паскаля, и, несмотря на то, что это мертвый язык, ни капли не жалею о времени на него потраченном.
Там проще всего понять именно суть программирования, не костылянство основанное на копипасте, а именно создании приложения.
Сейчас если человек хочет писать сайты, он идет и качает вордпресс и видео курс к нему. Через неделю у него есть сайт и уверенность в том, что человек теперь веб-программист
никто не идет в программирование с целью делать сайты.
А я вот много таких знаю. Сайты делать это нынче реально круто.
А вот делать сайты люди не хотят, в особенности дети.
Ещё как хотят.
Если же задача как можно быстрее войти в индустрию, присоединиться к интересным общественным проектам или даже деньгам (и не растерять по дороге энтузиазм), увы, желательно остановить выбор на чём-то менее академичном.
Если не хочется тыкать палкой в мертвяков, то есть Go. Там всё так строго, что можно научить обезьянку
for i in range (0, len(data)):
sum = sum + sqrt(data[i])
Потому что человек освоил C и теперь ему море по колено. Но главная моя мысль — оно точно надо 5 лет учить Си, чтобы потом быстро выучивать «практически любой мейнстримный язык» и этот Си больше не вспоминать? Может быть есть более эффективные методы?
А почему вы вообще сравниваете программирование с медициной? Чтобы стать хирургом — надо долго учиться, а программирование многие осваивают сами за год-два на достаточном уровне.
Понимаете — медициной тоже можно «на разных уровнях» заниматься. Можно травки заваривать и к больному месту прикладывать (и неплохо зарабатывать на этом, кстати), а можно — реально лечить.
С программированием — та же фигня: умение «что-то такое изобразить» — это один навык, умение программировать и работать над большими системами в большой команде — другой.
Вас так послушаешь, так программирование — это сплошная rocket science, а как посмотришь вакансии — большая часть 1С, Java-энтерпрайз, сайты-визитки, мобильные игры…
Впрочем если подходить формально, то, к примеру в США, хирургу нужно учиться 8 лет, а потом ещё от 3-х до 8-ми лет проходить практику, прежде чем он сможет оперировать.
В тоже время студенты-третьекурсники и всякие undergraduate уже вполне нормально находят работу в области программирования и работают в командах. Кстати и соответствующие опросы на хабре показывают, что большинство людей в этой отрасли не смотрит на образование, а смотрит на результаты собеседования — ничего, работают.
С другой стороны, сплошь и рядом поделия крайне профессиональных контор, к которым выходят патчи сразу после релизов. Представьте себе такого хирурга, м?
Я, конечно, понимаю, что хочется свою профессию и себя ставить поближе к чему-то вроде квантовой физики, а не к чему-то вроде автослесарного дела, но читать это чрезмерное возвеличивание программерского дела немного раздражает. Особенно при сегодняшних очень скромных успехах в области обеспечения надёжности и безопасности программных продуктов, причём у крупнейших контор — лидеров рынка.
А «опросы на Хабре» показывают больше «хотелки» людей, чем реальное состояние рынка труда.
А насчёт «надёжности и безопасности»… Посмотрим на какую-нибудь новость про безопасность ПО. Если скормить проигрывателю «специальным образом сконструированный файл» — то у него случится «бяда». О как. Ужос. А что будет если скормить даже не «специальным образом сконструированную грампластинку», а всего-навсего арбазивный круг любому проигрывателю грампластинок?
В ПО действительно куча уязвимостей и дыр — но безопасность ПО не хуже, а на порядок лучше, чем в любом другом оборудовании. Если ваш холодильник сгорит из-за того, что на него сильно и резко неправильное напряжение подадут — то это даже не будет считаться проблемой в его конструкции! А в ПО подобное же — повод для экстренного выпуска «патчей сразу после релизов».
Не столько завышать оценку людей, которые занимаются программированием, но и занижать её тоже не стоит — если бы каждый второй мог этому «с полпинка» научиться, то не было бы столько незакрытых вакансий предлагающих (как по меркам некомпьютерных областей) очень хорошие деньги.
Я и не говорю, что программирование — это неквалифицированная работа. Но и с работой, требующей высокой квалификации (как хирурга), оно не сравнимо.
безопасность ПО не хуже, а на порядок лучше, чем в любом другом оборудовании
Поймал радиоприёмник специальным образом сформированный радиосигнал — превратился в подслушивающее устройство, проехала машина по специальным образом сформированной дороге — руль начали крутить за вас злоумышленники, положили в холодильник специальным образом сформированный продукт — он перестал охлаждать и начал портить продукты, занесли в лифт специальным образом сформированный свёрток — лифт превратился в ловушку, отправьте SMS, чтобы выбраться. Знакомо?
При этом способы формальной верификации разумеется, существуют — ещё Дейкстра об этом писал, но все эти крутые фирмы почему-то продолжают пользоваться странными подходами вроде юнит-тестирования, которое, как пишут в любой книжке по тестированию, "не может на 100% верифицировать корректность работы программы".
Сервер упал — сервер подняли или включился резервный. С пациентом так не получится.
В программном коде написал что-то не то, скомпилировал, не работает — нажал Ctrl-Z. Если попало в релиз — накатал патч. В хирургии резанул что-то не то — нажать Ctrl-Z уже не получится.
Например даже в такой "банальной" области, как радиоизмерения, цена случайной ошибки гораздо выше, чем в программировании — можно легко сжечь дорогостоящий прибор, например. Функции Undo нет.
Сервер упал — сервер подняли или включился резервный. С пациентом так не получится.
А если речь идёт о программировании инструментов для хирурга? Или если водитель нажал тормоз, а тут как раз JVM решила сборщик мусора запустить?
Я так подозреваю, что на авто ставить JVM со сборщиком мусора — не самая лучшая идея…
Вот именно!
К любому программному обеспечению для автомобилей или для сердечных стимуляторов — очень жёсткие требования.
Помните историю с Therac 25 (аппарат лучевой терапии)? В его предшественнике были такие аппаратные цепи, в 25 это убрали "за ненужностью". А код-то оказался с гнильцой, и выяснилось, что та предыдущая модель не убивала людей только благодаря аппаратным блокировкам.
И это вовсе не про джаву речь, а про культуру программирования, ассемблер тут и там, где он неуместен и трюки в коде…
Мне странно, что здесь некоторые проголосовали за Си или C++ — Си еще куда не шло, но даже там лишние заморочки с указателями и другая специфика, которая будет только мешать усвоить базовые навыки программирования и сбивать с толку. Ну а С++ вообще тот еще лес для новичка.
Если же время поджимает и есть конкретная задача, то ты выбираешь тот язык, который требуется для задачи и изучаешь усиленно именно его.
— Что выбрать Ауди, Мерсдес, БМВ, Порше или Феррари?
— Да что тут думать?! У меня Феррари, Феррари лучшая первая машина!
— Спасибо за совет, да феррари супер машина! Но мне как-то больше нравится БМВ, хоть я на ней и не ездил…
— БМВ? Да ты что?! Как можно сравнивать Феррари и БМВ?!
— Ну ты знаешь… просто вот нравится и все… внешний вид, салон, приборная панель, ангельские глазки…
— Привет парни, о чем говорите? Ооо… о первой машине? Так я вам скажу, лучшая первая машина это Мерседес!
— Фууу… Феррари зэ бэст!
— Я как бы хочу первую БМВ, феррари может потом когда-нибудь…
— Нееее… если уж потом, так Мерседес! На крайняк Ауди купи, она хоть тоже немецкая!
— О! Привет мужики! Я тут вчера Порше купил… Тачка огонь! О чем болтаете?
— …
и тут выползают они: ВАЗ! Начинать нужно с ВАЗа! Это конструктор! Ты потом сможешь разобраться и починить любой автомобиль!
Так в (относительно, так-то лет двадцать пять уже) современных ВАЗах двигателем управляет такая же электроника: собирает данные с гирлянд датчиков, управляет форсунками инжектора… Часто не просто такая же, а та же самая электроника.
Но даже и без этого, при желании, знания вполне переносимы. У меня тут перед глазами пример такого тазовода, водителя 2106 (которая старше него самого), он недавно пересел на Октавию, и теперь копается ещё и в ней, причём довольно свободно, хотя шестёрка как раз ещё без этой самой современной электроники.
Машина — ЯП. Вы же скорей проводите аналогию между копанием в исходном коде ЯП и разборкой авто любой марки. Зачем вам копаться в феррари каждый день? Вы ездить на ней будете. А ремонтировать ее будут другие ))). У вас же 99,5 млрд долларов. В моей пятничной фантасмагории не проводится такой аналогии )) короче, и ВАЗа тоже не было.
На меня посмотрели, как на первокласника, и сказали «Основы, надо знать основы, молодой человек. А язык изучается за два-три месяца». :)
Извините, я из МИРЭА (в прошлом) :)
Но основы то знать, конечно, стоит. Вообще спрос на программистов с крепким базовым образованием всегда выше.
Но по отзывам, специалист она хороший.
Подтверждается ваш стаж в РФ вашей трудовой книжкой (на основании которой составляется юридически значимый документ и юридически значимый перевод к нему).
Моим первым компьютером был ZX Спектрум 48k, программы и игры на кассетах, в качестве встроенного языка Basic. Выбирать было не из чего. Когда появился нормальный комп на Intel Pentium2, я начал изучать Borland Delphi 4, ибо друзья показали и родители подарили книгу. Когда на третьем курсе универа пришел устраиваться на первую работу, мне в шутку сказали, что «за слова Delphi и Pascal у нас бьют по морде». Пришлось учить C\C++.
Для первого языка и изучения основ и алгоритмов(в школе) я бы посоветовал простой язык: С, Pascal, Basic.
Для студентов универа зависит от конкретной специализации: Java, C++, Python, PHP, Haskell…
Вот вам ряд вводных для возможно более точного ответа на вопрос:
Мне условных лет 18 и я только закончил школу. Допустим я «уверенный пользователь пк» и например в общих чертах понимаю что такое двоичное исчисление и зачем нужны «драйвера».
Мне нравится сидеть за компьютером играть в игры и смотреть сайты.
Я знаю что «программисты хорошо получают» и в целом «востребованы на рынке труда» и поэтому я хочу стать сферическим программистом в вакууме. Что бы и деньги и женщины и в игры играть и при любой возникшей проблеме тут же «написать программу что бы ее решить»
Что мне начать учить? И зачем?
Успешные программисты это, наверное, Линус Торвальд, Роберт Мартин и какой-нибудь Ханссон Давид Хейнемейер?
Интересно почитать биографию средненького такого программиста, который просто нормально зарабатывает, а не всяких звёзд.
-меня укусил другой программист...
Сомневаюсь, что при таком подходе кто-то что-то толковое расскажет, имхо самое лучшее — это посещать конференции — после пары-тройки если не просто ходить, а еще и с народом там общаться — будет более-менее понятны направления. Там люди более расположены к общению, чем в личке :)
Я знаю что «программисты хорошо получают» и в целом «востребованы на рынке труда» и поэтому я хочу стать сферическим программистом в вакууме.
Что мне начать учить? И зачем?
Имхо, с такой мотивацией вообще бесполезно что-то учить.
Если уж программировать, то только тогда, когда не можешь не программировать :-)
Зато, если хочешь программировать чтобы получать деньги — всякие дурацкие вопросы про то, какой язык учить отпадают сами собой. Смотришь средние зарплаты, выбираешь где больше и вперёд.
Ну да, а потом 20 лет джуниором работаешь, мечтая о средней зарплате xD
20 лет назад был 1996 год. И программирование как отрасль было совсем другим. И уж точно никто не думал, что там можно зарабатывать серьёзные деньги.
Поэтому ваше утверждение нельзя подтвердить никаким примером совсем.
Утверждение утрированно конечно, но я лично видел людей, которые пытаются устроиться на нормальную должность и даже где-то работали вроде как программистами более 5 лет, но по уровню знаний находятся где-то в районе плинтуса. Т.е. в следствии дефицита кадров их куда-то берут от безысходности, но у них нет стимула развиваться.
JS явно не очень подходит как первый язык, как минимум потому, что нет строгой типизации, человеку после js будет сложновато, на мой взгляд, перейти на тот же С, а вот наоборот — запросто.
Скажу Вам по секрету, что в С тоже нет строгой типизации.
А по существу, я бы обобщил, что любой язык со слабой типизацией плохо подходит в качестве первого.
Я программировал на бейсике, не умея произносить английские буквы. Для каждого оператора у меня было "название" на основе прочтения латиницы как надписей на русском. Команда "Веер" например.
Подозреваю, что из обычных языков на такую роль годится только питон, хотя жалею что в универе не было лиспа/хаскела, может лучше с них начинать, кажется что после них питон выучить проще чем наоборот.
Все равно потом при переходе на другой язык придется учить с нуля более традиционный подход к ООП. Придется переучивать что function это не пространство имен, это не модуль, это не интерфейс, это не класс и даже не метод — function это функция — все просто и очевидно, но не в JS
Плюс только в том что начать легко — консоль в браузере открыл и уже программируешь. )
Мой первый язык был JavaScript, ну… просто потому что я выбрал фронтенд. При изучении, скажем, как работают прототипы или this, каждый учебник сначала описывает что в js все работает не как в других языках программирования. И это с учетом того, что я не знаю как работает в других языках.
Для первого языка он точно не походит.
Можно программировать на русском. Есть бесплатный ИДЕ. Куча исходников. Очень востребован на рынке труда.
- В языке 1С нет нормального ООП (ни на классах, ни на прототипах); Там есть встроенные объекты, но создать свой, «с нуля» невозможно;
- В языке 1С нет и функциональной парадигмы, есть только 2 функции: «Шаблон» и «Выполнить»;
- В платформе 1С есть источник неочевидных багов (и плохого стиля): очень много данных и процедур (методов) доступны глобально, из любого места приложения;
- И ещё: я бы не хотел в 5 классе писать вместо игры или теста по географии «мини-склад». или мини-бухучёт;
- Сама среда разработки тоже обрушивает на
слабых духомнеподготовленных много ненужных понятий.
По мне, так хорош Lua.
Современный js на бекенд сопоставим по скорости с java компилируемым языком.
А что ж Вы ссылку не добавили на сопоставление? Нужна скорость — нужен компилятор, тут без вариантов.
Вы видите то, что хотите видеть… Node.JS сейчас там же, где и все остальные интерпретаторы с JIT, будь то PyPy, LuaJIT или Hack. Кроме того JIT это не свойство языка, т.е. ничто не мешает добавить его в любой интерпретатор, были бы финансы.
Ну и самое главное: везде, где нужна скорость при использовании интерпретируемого языка, как использовали биндинги к C-либам, так и будут использовать. Поэтому к реальным задачам все эти бенчмарки относятся весьма косвенно.
значительным финансовым вливанием Google в V8
Понятно, что финансы конвертируются в ресурсы, выделяемые разработке, и это собственно основной фактор. Но насчёт пятикратного превосходства в реальных задачах хотелось бы узнать поподробнее… Какого рода задачи? И не имело ли место сравнение одного ядра CPU против всех?
Ок, пускай цель как можно быстрее «войти в айти». Но в качестве кого, разработчика (техника) или программиста (инженера)? Имхо, если цель как можно быстрее стать вторым, то JavaScript должен быть минимум вторым языком, а лучше третьим, после Питона (с приоритетом на функциональность) и чего-то типа «C классами». На JavaScript из топ-10 мэйнстрим языков, имхо, сложнее всего обучаться именно программированию как инженерной дисциплине. Разработке, наверное, проще всего. Ну или на втором месте после после PHP.
Во, вот так у меня и вышло. Сидеть на уроке алгебры и демонстрировать, как я быстро "в уме" решаю квадраные уравнения, прикольно (а я сочинил программу для МК-61, которая их решает, и просто по мере зачитывания коэффициентов вводил в программу).
Проблема в том, что хочется поскорее начать рисовать картинки — не формы, упаси боже, а именно картинки, хотя бы графики функций — поскольку это даёт весьма резкий стимул и это можно кому-то показать. Для детей очень важно иметь возможность, например, похвастаться маме или папе, и если мама и папа не программисты, они не оценят программу для ПМК, но картинку, которая строится на экране — вполне.
Мне JavaScript кажется отличным вариантом для введения в программирования именно из-за указанных "недостатков". Само по себе несовершенство — отличный обучающий фактор: вы гарантированно зададитесь вопросом о том, как могло бы быть лучше, и это поможет глубже понять суть. Я помню как сам начал лучше понимать язык и его эволюцию, когда начал переключаться с JS на Dart и TypeScript.
обучение в духе "вы поняли, что JS — говно, достигли просветления, и достойны перехода на новый уровень — PHP"? :)
это похоже на "пусть психи прыгать научатся, а тогда мы им и воду в бассейн нальём", только в данном случае — "нальём, когда они догадаются, что там должна была быть вода"
Нет. Это просто способ лучше понять язык и его структуру, быстрее перейти от уровня "обезьянки" к чему-то более осмысленному, это некий стимул и наглядная демонстрация подходов "на собственной шкуре". Я, к примеру, толком разобрался с прототипным наследованием и с тем, что все в JS — это объекты, только основательно поиграв с другими языками, после чего и другие языки стали понятнее. Я никогда не скажу что JS — говно, это очень мощный инструмент с потрясающими возможностями. А при наличии определенного опыта, начинаешь понимать, что опасность огрести какие-то проблемы из-за мелочей типа неявного приведения типов вам грозит гораздо меньше, чем от ошибок проектирования на абстрактном уровне, где сам язык уже не так важен.
Язык — это стоящая за ним платформа и область применения, и если говорить о начале пути — то лучше выбрать ту платформу и область, в которой быстрее можно получить результат и фидбек, в которой есть еще кто-то, кроме условного тебя. Веб — это самая демократичная, открытая и бурно развивающаяся платформа. Тут есть место как для простейших экспериментов так и для мозговзрывающих концепций. Тут можно получить первое обоснованное представление о том, куда тебе дальше хочется двигаться. Определяющими будут именно ваши первые достижения, они запустят цепочку перестроений в вашем мозгу, которая, возможно, сделает из вас настоящего программиста. И царствует в вебе именно JavaScript, а не какой-то условный Pascal, на котором "не собираешься писать и нафиг его тогда вообще учить". В любом случае, достичь чего-то заметного в программировании суждено далеко не всем, в силу индивидуальных способностей, поэтому, даже если вы начнете с какой-то совсем уж эзотерической штуковины, далеко не факт, что она откроет для вас дверь к чему-то стоящему. "JS сейчас везде" — это не проблема, это офигенная возможность, которой надо пользоваться.
В обучении чему-то сложному важна такая штука как "мотивация", а она подразумевает стремление к некому результату и его оценке. Новые знания более всего интересны именно своей применимостью. И порой, как я уже писал, именно первые результаты вам наиболее доходчивым образом подскажут где стоит "копать глубже", без них вы будете витать в абстрактных облаках и окажетесь неспособны, в определенный момент, к какой-либо практике, как сейчас многие выпускники ВУЗов. Вы ничего не будете знать о реальном качестве результатов без практики. Ну и жизнь не такая длинная, чтобы 20 лет учится "на кошках" ради своего гипотетического "звездного часа" в реальном проекте. Насчет JS — вы очень предвзяты, он совсем не так плох как об этом модно сейчас говорить.
Если человек не любит сам процесс программирования, а хочет рисовать картинки, тыкать кнопки и делать игры с корованами, то, может быть, это вообще не его?
Крайне важный вопрос. Очень многие известные программисты утверждают, что они ненавидят программировать, а любят получать результаты. Любопытно — с вашей точки зрения — какой программист лучше — который любит процесс программирования и умеет программировать, или который любит получать результаты, а само программирование для него средство?
ИМХО на роль первого языка прекрасно подходит питон или раби — ввиду своей простоты, понятности и лаконичности. Заодно — приучает пользоваться отступами, структурировать код.
Т.е. первый язык должен иметь жесткий четкий синтаксис. Паскаль хорош тем, что там нужно объявлять переменные в начале, это учит думать и планировать наперед и экономить память, переиспользуя существующие переменные. Даже сейчас на C#, если метод содержит сложную логику, я объявляю переменные в начале. Не все, но ключевые.
Статическая типизация, подсказки решарпера, варнинги и статический анализ кода — это отличный безустанный ментор, который будет долбить голову «как правильно» с первого и до последнего дня, кроме того, обычно там есть подсказки как нужно сделать правильно.
Кроме того, язык должен позволять плавно наращивать сложность, т.е. начать например с консоли, потом а-ля блокнот из готовых блоков, потом уже что-то сложнее, красивее и кастомнее. Тут лидером для меня является платформа .NET, ну и C# в частности. Консоль — винформы — а дальше специализация, асп, впф, ксамарин, на выбор.
Я помню как я учил ЯП в школе, первым был бейсик на корвете, нужно было вводить номер строки и код, а потом запускать, посмотреть весь код сразу было сложно если он не влезал на экран. Это было очень сложно, держать все в памяти когда еще нет абстракций в мозгу для команд — сложно. Турбо бейсик уже был в виде IDE, в нем было работать намного легче. В борланд паскале был отличный отладчик, с ним понять как работают массивы и циклы в сложных задачах — намного проще.
Т.е. ИДЕ очень важна, ИДЕ должна позволять наращивать сложность, т.е. простые вещи должны делаться просто, а все сложное должно быть скрыто по умолчанию. Тут в лидерах для меня Делфи, очень интуитивно и очень легко зашла мне даже без мануалов. VS лохматых годов до 2003 года была ужасна, первое знакомство с ней испугало и отбило желание писать под винду в принципе, для создания проекта нужно было под сотню кликов и под десяток принятых решений. Современные версии намного лучше и понятнее, простые проекты создаются просто, есть примеры прямо в визарде создания. Кроме того последняя VS Community Edition в принципе бесплатная и содержит практически все возможности.
Думаю вы уже догадались, что я считаю идеальным кандидатом для первого языка C# + VS Community Edition.
Альтернатива — паскаль или бейсик который встроен в офис.
Почему бейсик из офиса — потому что у него сразу есть гуи и простые и понятные средства вводы и вывода информации.
Почему JS не подходит.
1) нет статической типизации, нет статического анализа кода
2) слишком гибкий синтаксис, но при этом каждый символ имеет вес, например пробелы и переносы строки
3) не понятно что делать с IDE, писать в блокноте — плохо для обучения, нет четкости. Искать и пробовать разные IDE — сложно для новичка. Хорошие IDE — платные.
4) для запуска простого приложения не достаточно JS, нужен еще и HTML. Для более сложных примеров — нужен CSS. А для более менее близких к продакшену нужна еще и серверная часть, и понимание взаимодействия с ней.
4+) из этого минуса, выплывает еще один, изначальная ориентация на верстку и дизайн, хотя почти все мои знакомые с хорошей зарплатой стараются избегать верстки за версту. А почти все проф фронт енды — не могут перейти на абстрактные слои, т.к. их задачи не предполагают этого, нужно отдельно доучиваться.
5) JS хоть и работает в браузерах на всех платформах, эффективные решения для многих платформ на нем писать не выйдет, т.е. он такой-же нишевый, как и все остальные. А размер ниши не сильно важен, т.к. все ниши примерно одинаково наполнены, конкуренция +\- одинаковая.
Ну и мое личное замечание насчет веб и мобильного направления. Да это очень активное и модное направление, да там много заказов, много вакансий, но посидев одно время на oDeskе перебирая все доступные вакансии, я заметил, что веб и мобильные заказы — не выгодные совершенно, они очень дешевые но при этом очень объемные, все хотят условно за 100-1000 уе сделать приложение под 3 платформы или под все браузеры и по быстрее. А сами проекты — скучный треш, типа очередной платформер с «нескучными обоями». Нормальных заказов оказалось меньше, чем на десктоп например. Даже те кто сидели на фулл тайме в соседней комнате, клепали приложения однодневки, скучные и однообразные.
экономить память, переиспользуя существующие переменные.
Я думаю компилятор должен сам с этим справиться, не надо делать за него его работу.
Насчет IDE, у меня есть твердое убеждение, что в какой то момент при обучении(пусть не сразу) человека надо выкинуть за пределы IDE и заставить скомпилировать проект из консоли, что бы устранить всю эту магию уровня сборки. Но может быть это относится больше к C/C++
Хотя тут есть другая сторона медали, после управляемых языков переходить на С++ очень не хочется. Посмотрев на все проблемы\оверхеды с памятью и указателями появляется мысль — да ну его так жить, лучше уж на Яву.
Кстати интересно как воспринимается эмоционально код на «не родных» ЯП.
Для меня Ява как женские застольные разговоры, много лишних слов, мало конкретики.
С++ как разговор двух физиков педантов, или как юридические документы, все очень дотошно, конкретно и с кучей уточнений.
Асм как инструкции для бытовой техники, дотошные и понятные даже самым глупым, в то-же время общая суть ускользает за деталями.
Ява скрипт как общение двух прожженных сантехников, где половина слов маты, а вторая половина местоимения. Из-за динамической типизации и замыкания.
Декларативные языки и языки разметки, как священописания. Пусть будет то, пусть будет это, а что получится — догадайся сам.
PS Не встречал ещё человека, который думал, что лучше всего начинать с JS…
Давайте будем честны: у всех языков свои проблемы. Мы пишем не на тех языках, которые лучше подходят, а на тех, которые нам более симпатичны. И все наши попытки отговорить от другого языка — лишь скрытая неприязнь/равнодушие к этому языку. Ничего рационального в нас и наших мнениях нет и быть не может. Мы люди, а не роботы.
Но если вопрос «так с чего же начать то?» остался висеть, то сделайте так: выберите сферу, которая вам интересна. Найдите опенсурсный проект по этой тематике, в который можно контрибьютить новые
Какой язык программирования стоит выучить первым? (ʇdıɹɔsɐʌɐɾ: ɯǝʚɯо ņıqнqvиʚɐdu)