Я ни в коей мере не утверждаю, что указанный мной способ лучший из возможных. Более того, я вовсе не уверен в том, что он вообще правильный. Возможно, если бы моим первым языком был не Си, а какой-либо из функциональных языков или ассемблеров, моё мнение было бы иным, и жизнь моя сложилось бы совсем по другому. Так что весь нижеизложенный материал воспринимайте со здоровым скептицизмом.
Немного личных воспоминаний
С детства я мечтал о карьере биолога, но в тринадцать лет, впервые ознакомившись с компьютером в школе, задумал стать крутым хакером. Когда у меня в пятнадцать лет появился регулярный доступ к компьютеру, первой мыслью было изучение программирования. Мой выбор пал на C++, была куплена книга из серии «Для чайников», но всё было ужасно скучным, непонятным и неинтересным. Уже тогда я понимал, что с C++ что-то не так. И сам ход изложения материала в книге начинался с краткого экскурса в функции, после чего сразу переходили к классам, причём всё объяснялось не на живых примерах, а на уровне глобальных абстракций. Авторы с увлечением рассказывали о прекрасном мире ООП, в котором нам посчастливится жить, про машины с разными функциями или животных с разным поведением. В общем, в то время изучение C++ и сама концепция ООП были заброшены.
Спустя несколько лет, во время учёбы в университете, я увидел в киоске маленькую книгу «Язык программирования Си», Брайана Кернигана и Денниса Ритчи. Купив её, я сразу же приступил к чтению. И о чудо! Всё было ясно, легко и ужасно интересно. Язык C очень маленький, простой и элегантный (я всё ещё так считаю), а сама книга была написана нормальным человеческим языком, не лишённым однако строгости. Я перечитывал её много раз, выполнял упражнения, и, таким образом, вскоре освоил этот язык и стандартную библиотеку функций.
Но на чистом Си много не напишешь, а мне хотелось писать серьёзные программы с красивой графикой. Программировал я в Slackware Linux, ибо в Windows как в среде программирования полностью разочаровался. В те времена я вообще много экспериментировал с разными системами, включая QNX и NetBSD. Но в свободных Unix системах выбор вменяемых графических библиотек был невелик: GTK+ и Qt. Причём вторая была написана на C++, с которым я не желал связываться, а в первой не было ясно вообще, как работать. И, если мне не изменила память, их редакторы интерфейсов генерировали огромный код, который ещё нужно было вставлять в свою программу, а не ресурсные файлы, что казалось мне совершенно ужасным.
Так бы я и не начал карьеру, если бы случайно не познакомился с Mac OS X, которую недавно портировали на Intel процессоры. Попросив у знакомого диск с Mac OS X 10.5 Leopard, я установил её на свой HackBook и первый раз ощутил себя на Земле Обетованной.
Помня о своём неудачном первом разе, я ещё долгое время скептически относился к объектно-ориентированному программированию. В начале даже планировал писать программы на чистом Си, используя библиотеку Carbon. И, как выяснилось – зря. Objective-C я изучил по официальному руководству компании NeXT – Object-oriented programming and the Objective-C language. В те времена изучающих новый язык ещё не считали поголовно идиотами или школьниками, поэтому книга написана нормальным языком, а авторы предполагают знание Си и общее представление о программировании. Оказалось, что ООП – это легко, интересно и очень удобно, а объекты – вовсе не абстрактные сущности, а всего лишь структуры, объединённые с функциями. На мой взгляд, именно так и нужно рассказывать основы объектно-ориентированного программирования.
В Xcode и основам Mac OS X я разобрался по замечательным урокам Алексея Борескова. После чего сразу же нырнул в Mac Developer Library, взялся за изучение официальных руководств по Cocoa и прочим библиотекам, параллельно начав писать программы.
Моим первым серьёзным проектом было портирование уроков по OpenGL с Windows на Mac OS X, которое растянулось на целый год. Лишь закончив его, я почувствовал себя достаточно уверенно, чтобы устроиться на регулярную оплачиваемую работу.
Изучая Objective-C, нельзя не услышать о Smalltalk, ибо на него очень часто ссылаются в материалах по Objective-C, видимо, извиняясь за непривычный синтаксис. Но Smalltalk был похож на Неуловимого Джо – все о нём слышали, но мало кто его видел или использовал. В конце концов и мне стало интересно, откуда есть пошла русская земля.
Узнав, что компания Cincom – лидер в сфере решений на Smalltalk – в рекламных целях предоставляет свои инструменты для некоммерческого использования, я сразу же заказал их. Менее чем несколько недель в мою дверь постучал курьер и вручил мне фирменную коробку с несколькими CD дисками и официальным руководством. Всё было совершенно бесплатно, даже за доставку не пришлось платить. На одном из дисков обнаружился VisualWorks – одна из самых мощных и быстрых коммерческих сред по разработке на Smalltalk в мире.
После я узнал про Squeak – свободную реализацию Smalltalk, основанную на оригинальной версии Smalltalk-80, – и познакомился со многими её разработчиками. Для обучения и исследований он подходит намного больше, чем прочие версии. Кстати, сообщество программистов на Smalltalk очень дружное.
Почти все серьёзные проекты являются кроссплатформенными, и их ядра написаны на C++, ибо Objective-C очень мало распространён за пределами Apple экосистемы. Главным образом из-за отсутствия удобных средств разработки. (Будем надеяться, что благодаря LLVM ситуация вскоре улучшится.) Так что мне пришлось изучить C++, несмотря на явную нелюбовь к нему. К счастью, к этому времени я уже научился отделять зёрна от плевел.
Впрочем, хакером я так и не стал.
Порядок изучения языков
C – первый язык
Это маленький (всего 32 ключевых слова в C89, 37 слов в C99 и 44 слова в C11) императивный язык, и его первичное изучение не займёт у вас много времени. В то же время C – очень мощный промышленный язык. Главным образом используется в системном программировании, написании аппаратно независимых компонент операционных систем, компиляторов и трансляторов языков, библиотек, программировании микроконтроллеров. По версии TIOBE Programming Community Index Си всё ещё лидирует по использованию, изредка вежливо уступая первенство Java.
/* Hello world in C */
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
printf("Hello World!\n");
return EXIT_SUCCESS;
}
Objective-C – второй язык
Он представляет собой очень тонкий слой поверх чистого Си. Все знания, полученные при изучении Си понадобятся вам в Objective-C. Причём объектно-ориентированная парадигма концептуально и синтаксически отделена от процедурной: в нём вы никогда не спутаете вызов функции и посылку сообщения. Основное его применение – создание пользовательских программ на устройствах компании Apple.
/* Hello world in Objective C */
#import <Foundation/Foundation.h>
int main (int argc, const char *argv[])
{
NSAutoreleasePool *pool = [NSAutoreleasePool new];
NSLog (@"Hello, World!\n");
[pool drain];
return 0;
}
Smalltalk – третий язык
После Objective-C он покажется вам очень знакомым. И не зря, ведь именно его синтаксис и объектная модель были положены в основу Objective-C. Интересен прежде всего чистой реализацией объектно-ориентированной парадигмы. Все конструкции языка, включая условия, циклы, управляющие структуры и операторы, реализованы через механизм сообщений и вынесены в стандартную библиотеку классов. Несмотря на малое распространение он используется в крупных сложных проектах, где важна масштабируемость, гибкость и возможность изменений во время работы. Например, в финансовой сфере (Kapital – система оценки и управления рисками в JPMorgan), управлении производством (CIM в Texas Instruments), логистике (IRIS-2 в Orient Overseas Container Lines), страховании (Desjardins General Insurance Group) и прочих.
"Hello world in Smalltalk"
Transcript show: 'Hello World!'; cr.
После изучения указанных языков, все прочие можно учить в любом порядке, в зависимости от ваших личных предпочтений. Ниже я приведу список наиболее важных и интересных языков.
C++
Очень избыточный (число ключевых слов превалило за 100), запутанный и сложный в изучении язык, со множеством исключений и массовыми нарушениями ОО парадигмы. Но если вы хотите работать в индустрии, знать его нужно, так как альтернативы ему не предвидится. На C++ написана большая часть научных и инженерных программ, игр, фото- видео- аудиоредакторов и много чего ещё. После того, как Objective-C и Smalltalk сформировали у вас правильное представление об ООП и программировании, C++ уже не сможет повредить ваш разум. Но всё равно будьте очень осторожны. Вообще, слово «знать» в применении к C++ имеет несколько иное значение, ибо знать его в том же смысле, в каком можно знать, например, Objective-C или Java мало реально. Хорошая новость: в большинстве случаев для успешной работы вам нужно освоить лишь небольшое подмножество языка. Великолепным примером грамотного использования C++ является I/O Kit – интерфейс программирования драйверов в Mac OS X.
// Hello world in C++
#include <iostream>
int main()
{
std::cout << "Hello World!\n";
return 0;
}
Assembler
Ассемблеров существует очень много, намного больше, чем различных архитектур процессоров, так как они представляет собой всего лишь мнемонические коды машинных команд и различаются в разных операционных системах и их версиях. В настоящее время на них не пишут большие программы (исключая, разве что Demo сцену). Однако они широко используются при написании компьютерных вирусов и антивирусов, аппаратно зависимых компонент операционных систем, программировании микроконтроллеров, в реверсивной инженерии и отладке программ.
# Hello World in GNU Assembler on Mac OS X 10.8 using System V AMD64 ABI calling convention
.data
_hello:
.asciz "Hello world!\n"
.text
.globl _main
_main:
subq $8, %rsp
movb $0, %al
leaq _hello(%rip), %rdi
call _printf
movq $0, %rdi
call _exit
JavaScript
Пожалуй, главный язык программирования Всемирной Паутины. Основное его применение – создание динамических web страниц на клиентской стороне. Каждый браузер снабжён интерпретатором и средствами для анализа и разработки на нём. Если вы хотите заниматься web программированием, JavaScript – ваш выбор. В нём реализованы по меньшей мере три парадигмы: процедурная, функциональная и объектно-ориентированная, причём последняя основана на прототипах. На первый взгляд JavaScript кажется очень лёгким, ибо позволяет писать в C-подобной манере, но в реальности он сложный. Большинство JavaScript разработчиков программируют не с использованием языка и даже не на языке, а на одной из библиотек.
// Hello world in JavaScript
document.write("Hello World!");
Язык Ada
По крайней мере его стоит выучить, чтобы шокировать знакомых священников громким заявлением. Шучу. Благодаря правильному дизайну, многочисленным встроенным механизмам и проверкам Ada является одним из самых безопасных языков программирования. Вряд ли вы будете регулярно использовать его (если, конечно, вам не повезло работать в Министерстве Обороны США, авиационной или космической сфере), но ознакомиться с ним крайне полезно. После его изучения вы узнаете, каким должен был быть C++.
-- Hello world in Ada
with Ada.Text_IO; use Ada.Text_IO;
procedure Hello is
begin
Put_Line ("Hello, world!");
end Hello;
Scheme
Функциональный язык, разработанный в Массачусетском Технологическом Институте специально для обучения студентов программированию. Один из диалектов знаменитого Lisp. Интересен своей элегантностью и минимализмом. В промышленности не замечен, главным образом используется (и весьма успешно) в образовательных учреждениях. Своё знакомство с миром функционального программирования лучше начать именно с него.
;; Hello world in Scheme
(begin (display "Hello, World!")
(newline))
Знание разных языков позволит вам выбирать нужный язык под конкретную задачу, а не наоборот.
Особое мнение
Многие авторы советуют первыми изучать скриптовые языки высокого уровня, такие, как Shell, Perl, JavaScript или Scheme. Но лично я рекомендую первым языком учить именно Си. Скриптовые языки с автоматическим управлением памятью, скрывающие всю сложную работу с указателями глубоко в недрах программы, действительно легче в освоении, но все их преимущества можно в полной мере понять и оценить лишь после изучения языка уровнем ниже.
Когда вы научились считать каждый байт, привыкли проверять границы массивов, освоили ручное управление памятью и разобрались с указателями и адресной арифметикой, переход на любой скриптовый язык покажется вам лёгкой прогулкой. Обратное же, как правило, не верно. Если вы привыкли, что ваш интерпретатор всё делает за вас, освоиться в C или C++ будет намного сложнее, особенно, в процессе смены специализации. Ещё вы будете знать, что происходит под капотом вашей программы, и сможете примерно представлять в уме, как могли бы выглядеть на Си выражения используемого языка.
По схожей причине ряд учёных предлагает изучать физику не с классической, а с упрощённой версии квантовой механики. Чтобы у студентов сразу формировалось правильное представление о мире.
Более того, поскольку практически все интерпретаторы и компиляторы языков высокого уровня, а также их модули расширений (во всяком случае самые важные их компоненты) написаны на C, его знание будет вам очень полезным, если вы захотите внести в них изменения или исправления.
Также не нужно выбирать первым объектно-ориентированный язык. Не бегите впереди паровоза. Дело в том, что временные затраты на проектирование и реализацию классов весьма существенны. И в маленьких учебных программах польза от них не очевидна. ООП является логическим расширением процедурного программирования, и изучать его лучше именно в таком ключе. После того, как вы написали несколько сложных программ на процедурном языке, естественным путём пришли к объектным моделям, вам сразу будут ясны все преимущества языков, реализующих объектно-ориентированную парадигму. И ещё, на первом языке обычно изучают основы программирования и алгоритмы, а применение объектной парадигмы, требующей немалого объёма «лишней» работы, будет отвлекать ваше внимание.
Хороший пример объектной модели, реализованной на языке C – библиотека CoreFoundation в Mac OS X.
Как учить язык?
Изучение языка программирования очень похоже на изучение обычного человеческого языка общения. Чтобы выучить новый язык вам понадобятся:
Во-первых, хороший учебник. Не «Для чайников» и не «За 21 день». Лучше, если это будет учебник именно по языку, а не руководство по созданию и выкладыванию игры в App Store (в котором процессу выкладывания посвящено больше времени, чем самому программированию). Во-вторых, стандарт языка ANSI/ISO и справочник по стандартной библиотеке. И, в-третьих, учебные и реальные примеры, которые можно найти в Сети.
Читайте учебники, выполняйте упражнения, изучайте чужие и пишите свои учебные примеры. Экспериментируйте с языком, например, попробуйте реализовать на нём несвойственные ему парадигмы. Полезное упражнение не только поможет вам лучше прочувствовать язык, его достоинства и недостатки, но и приведёт вас к правильной мысли – не существует универсальных языков. Бывают языки хорошо или плохо спроектированные.
Лучшее упражнение – это написание небольших программ, реализующих различные структуры данных и алгоритмы – деревья, списки, таблицы, графы, поиск и сортировку из книги «Алгоритмы. Построение и анализ», Томас Кормен, Чарльз Лейзерсон, Рональд Ривест, Клиффорд Штайн (Introduction to Algorithms by Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest and Clifford Stein). Несложные функции стандартной библиотеки или утилиты командной строки. Не нужно пытаться сразу писать большие и сложные программы, всё равно вы ещё плохо знаете язык.
Ещё один хороший способ лучше разобраться в языке – портировать на него учебные примеры или реальную программу с другого языка. По сравнению с разработкой программы с нуля, при портировании у вас уже есть образец перед глазами, и вы сможете всецело сфокусироваться на языке, а не на архитектуре и проектировании. В отличие от многих моих коллег лично я не считаю портирование скучным занятием.
У многих на фоне первых успехов возникает желание сразу начать писать большие серьёзные программы. Я крайне не рекомендую вам следовать их примеру. Взявшись за сложный проект, вы через месяц обнаружите, что ваш первый код был ужасен и приметесь его переписывать, вполне возможно, вам потребуется ещё несколько итераций. В результате вы потратите время и силы на то, что нужно отрабатывать на учебных или небольших программах. Так что не торопитесь – к счастью, примерно за год изучения и упражнений легко можно выйти на приемлемый уровень коммерческой разработки.
Даже если вы опытный программист, лучше вначале разберитесь в языке – как известно, программисты на Fortran (в основном касается ранних версий) могут на любом языке писать как на Fortran. Дело в том, что язык программирования не ограничивается синтаксисом и семантикой, кроме них он включает в себя набор шаблонов, приёмов, идиом и парадигм характерных именно для него. За неделю разобраться в них не представляется возможным.
Подпишитесь на каналы и новостные группы, списки рассылки, посвящённые вашему языку. Ценным источником информации и ответов на многие вопросы являются профильные сообщества в stackexchange.com и аналогичных ресурсах.
В последнее время получил широкое распространение иная стратегия – нацеленная на немедленный результат. Появилось множество книг и курсов, обещающих сделать из человека без малейшего представления о программировании высококлассного специалиста менее чем за месяц. Немало людей посещают подобные курсы (за приличные деньги), учатся писать screensaver, радостно публикуют его в Сети и получает на выходе красивый сертификат с которым бегут устраиваться в фирмы. Подобный подход опасен тем, что создаёт иллюзию знания: человек наспех выучивает одну технологию (как правило не самую лучшую) и считает её единственно возможной.
Заключение
До сих пор речь шла о языках программирования. Но языки представляют собой лишь одну ось в многомерном пространстве программной инженерии. Хорошее знание языков необходимо, но, вообще говоря, недостаточно для разработки программ. Не менее важно знание принципов проектирования программ, алгоритмов, предметной сферы. Всё это нужно изучать параллельно. Продолжая аналогию с реальным миром, можно сказать, что кроме развёрнутых измерений, которые благодаря объёму рынка хорошо видны, существует намного большее число свёрнутых маленьких измерений. Обычно их не видно, но без них привычный мир бы не существовал. Чаще всего именно узких нишах находится наиболее интересная инженерная работа и исследования.
Комментарии (314)
SD_Freeman
07.07.2016 07:37+2Согласен с автором, чтобы всецело понимать процесс, которым занимаешься, нужно знать его основы. Другое дело, что, в частных случаях нет необходимости в понимании той, или иной, основы, наверное. Для того и есть программисты, которые знают, преимущественно один язык высокого уровня.
Balek
07.07.2016 09:39+7Для меня ВМКашная последовательность изучения канонична: Паскаль, Ассемблер, Си, Си++, Лисп, Пролог. Т.е. сначала нужно просто понять, что такое алгоритм. А потом идти от самых глубин. Потому что, нужно знать, как работает процессор. А изучая Си, нужно понимать, что это платформонезависимый Ассемблер. А дальше нужно ознакомиться с различными парадигмами. При этом Си++, мне кажется, знать необходимо.
DistortNeo
07.07.2016 11:10+5Полностью C++ знать невозможно. Для его знания на более-менее приемлемом уровне необходимо не менее 2 лет практики.
Balek
07.07.2016 11:45+3Честно говоря, я не понимаю всего этого хейтерства вокруг Си++. Есть такая замечательная книга «С++ за 21 день». Не думаю, что мои знания выходят за рамки этой книги, даже с учетом года изучения в университете. При этом мне не попадалось реального кода, который был бы непонятен. Где же используется весь тот сложный Си++, о котором так много пишут на Хабре? Наверное, у меня мало опыта, но тот опыт, что есть, считаю весьма полезным. И он мне говорит, что Си++ не такой уж сложный.
DistortNeo
07.07.2016 12:09+5Всё дело в том, что между «писать на C++» и «эффективно писать на C++» — огромная пропасть.
Ничто не мешает писать на C++ как на C с классами — но в этом случае я бы порекомендовал Java или C# — это уменьшило бы время разработки.
C++ сложен кучей нюансов, которые непременно вылезут в процессе разработки (привет, stackoverflow). Есть ещё C++11 и C++14, которые внесли много нового, в т.ч. и принципиально нового.
potan
07.07.2016 12:59+2Вы библиотеками из Boost много пользовались или ограничились STL?
MacIn
08.07.2016 15:15Буст настолько запутан?
DistortNeo
08.07.2016 20:59Да, буст очень запутан. Если внутренности STL ещё можно худо-бедно читать, то в Boost лучше вообще не залезать, и вот почему:
1. Boost кроссплатформенен — мы увидим мешанину из директив препроцессора.
2. Boost позволяет эмулировать возможности новых стандартов C++ на старых компиляторах: например, лямбды, functional, move semantics, variadic templates. Какими костылями и какой ценой это было достигнуто, лучше не смотреть.
3. Время компиляции программы с Boost на порядок выше, чем на STL. У меня есть простой проект с Boost, который делает простую фильтрацию изображений, который компилируется 30 секунд, и аналогичный без Boost, который компилируется за секунду. Если есть возможность отказаться от буста — лучше отказаться.
Но в целом Boost не так плох. Boost можно рассматривать как передний край развития C++. Именно благодаря Boost C++ эволюционирует: вещи из Boost переходят в стандарт C++ и становятся частью STL.
billyevans
09.07.2016 03:06Например вот
https://github.com/boostorg/dynamic_bitset/blob/develop/include/boost/dynamic_bitset/dynamic_bitset.hpp
В принципе все прочитать можно. Но местами оно переусложнено для портабельности и полноты API.DistortNeo
09.07.2016 11:38Приятно читать, однако.
А теперь взгляните вот сюда (отдельная библиотека boost.preprocessor):
https://github.com/boostorg/preprocessor/tree/develop/include/boost/preprocessor/tuple
Ну или сюда (кусок из boost.mpl):
https://github.com/boostorg/mpl/blob/develop/include/boost/mpl/aux_/preprocessed/msvc70/map.hpp
Symphel
07.07.2016 15:00+4Проблема C++ в том, что написать непонятный код на нем очень легко. Сделать непонятным код, который был понятным, добавив пару условий (и пару багов) — еще проще. А вот понять потом этот код и провести рефакторинг должным образом — задача другого порядка. В итоге без твердой руки в управлении проектом качества кода постепенно падает, особенно если «нужно быстрее».
Также вам передают привет простыни в описании ошибки при использовании шаблонов, проблемы с поддержкой современных фич в современных компиляторах, segmentation fault, толпы ifdef'ов, неявное приведение типов, heap/stack corruption и все прочее, что вы должны по долгу службы держать в голове, но не можете.
В итоге в каком-нибудь лохматом громоздком проекте, где многое писалось без использования STL просто потому, что тогда в нем были баги, это многое проще просто переписывать с нуля. Проблему, конечно, решает строгое следование гайдлайнам, но код, который попадает к вам в руки, часто про них не слышал.
Lauren
08.07.2016 10:22C++ очень похож на естественный язык. Сказать:«Я знаю полностью язык c++», — могут немногие, но это не беда, ведь в каждой «социальной группе» используется только его часть.Это эквивалентно правилу 2500 слов в английском языке. Если вы хотите не только «разговаривать» на языке, но и писать хорошие произведения, то нужно изучать С++ глубже. В культурном обществе употребление мата разрешается только спонтанно, а когда за речью не следят, матом разговаривают. Аналогично на с++ — одна и та же задача решается различными способами. Можно написть красиво и понятно, а можно ******(много мата). Однажды из-за проектной ошибки, один и тот же код писали разные програмисты разного уровня. Спектр решений на с++ меня шокировал, от чистого С до шаблонов.
Scf
08.07.2016 13:36Три года практики? Если кто-то говорит вам, что он знает С++ и у него нет очков и бороды, то он либо врет, либо просто не читал Александреску.
DistortNeo
08.07.2016 13:41-1Не-не, извращенства с шаблонами — это уже не эффективное программирование, а баловство.
Scf
08.07.2016 13:46+1STL и Boost — это сплошняком извращенства с шаблонами. А человек, который считает, что он знает С++, должен хотя бы уметь понять исходники.
MacIn
08.07.2016 15:14+2Это не то что бы ВМКашная последовательность, это каноничная. У нас единственно Ассемблер изучали после С++, до Лиспа с Прологом, как раз перед изучением «Организации ЭВМ».
Т.е. сначала нужно просто понять, что такое алгоритм. А потом идти от самых глубин
Золотые слова: последовательность «сначала машинная арифметика, потом Ассемблер, а уж потом что-нибудь еще» не работает. Человеку надо сначала влезть на ступеньку, с любым языком — будь то хоть Паскаль, хоть, прости господи, Бейсик. Почувствовать, попробовать программирование на вкус, а уж потом нырять.
DistortNeo
07.07.2016 11:08+13А вот я приверженец стратегии программирования, нацеленной на результат. Сначала ставим задачу, а затем с интересом её решаем, попутно изучая язык программирования. Переписывать через месяц код с новыми значениями — это нормально, это не трата времени, а естественный процесс обучения. А вот накапливать в течении года теорию и только потом приступить к практическую программированию — нереально.
Также я считаю, что не нужно смешивать следующие моменты:
1. Изучение архитектуры, логики и парадигм и технологий программирования.
2. Изучение синтаксиса языков.
3. Изучение алгоритмов и структур данных.
Мне становится грустно, когда я вижу студентов, которые без уверенного знания архитектуры и синтаксиса языка сразу лезут в алгоритмы.
Роль учебников для каждого индивидуальна. Я считаю чтение учебников скучным, для меня это пустая трата времени, т.к. теория без практики не откладывается. А если и использую учебники, то исключительно как документацию и справочный материал — впрочем, сейчас всё то же самое есть в интернете.
Многие, например, очень настойчиво советуют всякие модные книги по написанию совершенного кода и паттернам. Новичку эти книги будут вредны. Например, паттерн — это просто способ оформления кода с определённой логикой, а не готовое решение, которое обязательно нужно куда-нибудь воткнуть.
Ещё крайне важно знать английский язык. Потому что документация и обучающие примеры в подавляющем большинстве будут на английском.
arielf
07.07.2016 14:17+2Вы не поверите, но и мне в первую очередь важен результат. При условии, что вы уже профессионал. Но я против алчного желания мгновенного результата, когда человек лишь начал учёбу. В первое время изучения программирования результатом должно являться усвоение знаний. Начните уже воспринимать программирование как инженерное искусство и науку, а не как набор магических заклинаний.
Symphel
07.07.2016 14:34+3Программирование — это никак не наука. Программист не производит знание, он производит код. Есть специальный термин «компьютерные науки», но это не программирование само по себе.
Искусство тоже мимо, только если код не экспонат. Но мы все к этому стремимся, да.
Программирование — это инженерное дело, то есть ремесло. А в ремесле очень важен практический опыт и умение соотнести затраты и результат, которое с ним приходит.
senyaarseniy
07.07.2016 19:49+3Вы путаете программирование и кодинг. Кодеры производят код, а программисты также как и физики, матиматики и тд ищут решение проблемм.
Symphel
08.07.2016 08:35Нет слова «кодинг» в русском языке. Есть программирование — создание программ, и кодирование — процесс написания программного кода. Соотносятся они примерно как постройка дома и перекладывание кирпичей. Мы все-таки говорим о первом.
Физики и математики создают научное знание, программисты создают программы.
Решением проблем занимается человек абсолютно любой профессии, не было бы проблемы — его бы не звали.
eydemidov
08.07.2016 19:47Можете привести примеры работы «кодера»? Например, в типичной компании, разрабатывающей свой продукт. Что будут делать кодеры, и что будут делать программисты? Как этим понятиям соответсвуют Junior/Middle/Senior Developer из типичных вакансий?
Пока что я не уверен, что профессия «кодер» существует в 2016 году за пределами интернет форумов.DistortNeo
08.07.2016 21:11Лично я «кодерами» называю программистов, способных писать код, но не обладющих развитым аналитическим мышлением.
Кодер не способен осилить Кнута или Кормена. Кодер не может оценивать эффективность алгоритмов, в результате чего программа может начать тормозить на пустом месте. Кодер не способен решать задачи, где требуется применение математических методов. Кодер не способен придумать или реализовать какой-нибудь алгоритм, и т.д. Идея, надеюсь, понятна.
Например, была у меня пара студентов: с одной стороны, уже подрабатывали разработчиками, с другой — не могли решить элементарные задачи. Одна студентка-разработчица под iOS вообще убила: за год не смогла написать свёртку изображений (функция-велосипед пишется за 5 минут), потому что не понимала, как. Искала готовые решения, пытаясь разобраться с OpenCV, но так и смогла этого сделать. Пришлось в итоге её выгнать.eydemidov
08.07.2016 22:00Ну по вашей версии это тот же программист, просто хуже.
Мне больше интересна версия, где кодер и программист каким-то образом кардинально отличаются.
В англоязычных местах сегодня coder и programmer используются вполне себе взаимозаменяемо, и серьёзно топовые люди могут быть названы кодерами без всякой задней мысли.
Но в русскоязычных, почему-то, некотые (большинству пофиг, по-моему, они используют так же, как и англоязычные коллеги) умудрённые люди, программисты, любят это разграничение и используют, несмотря на отсутствие хоть какого-то чёткого определения и общепринятого понимания того, в чём всё-таки разница.
Возможно, это просто мой pet peeve, но такая двойственность (с одной стороны, говорят о том, как важно быть логичным и прочее, а с другой, без оглядки используют такое расплывчатое понятие) выглядит очень странно.
Напомнило TDD, почему-то. Часто сталкиваюсь, что в последнее время под «TDD» понимается тупо «пишите ли вы какие-нибудь тесты?».DistortNeo
08.07.2016 22:12В русском и английском многие слова имеют разный смысл. Так, слова «менеджер» и «manager» имеют разный смысл, «девелопер» и «developer» — тоже и т.д. Это вполне естественная эволюция значений слов при заимствовании.
А для философов даже слова «детерминированный» и «определённый» имеют разный смысл.
khim
08.07.2016 23:53Мне больше интересна версия, где кодер и программист каким-то образом кардинально отличаются.
Вы действительно не видите разницы? По-моему отличие между «кодером» и «программистом» — это всё то же самое различие между наукой и псевдонаукой, скажем алхимией и химией.
Алхимики ведь много интересных вещей изобрели. Больше того, многие учёные, заложившие фундамент современной науки ей увлекались. Тот же Ньютон вообще считал, что это — его самое главное дело в жизни, а Начала — это так, фигня, сочинение, которое Галлей его буквально заставил написать, блажь какая-то.
Но, тем не менее, это не помешало алхимикам толочься буквально на одном месте сотни лет! Просто потому что у тебя нет плана и объективного способа оценки результатов, то можно ходить кругами на одном месте годами.
Вот и описанная студентка-разработчица, судя по описанию, была занята поисками «философского камня». Что, глаз бешенного койота не подходит? Ну давай мочу доископаемого бизона попробуем. Вдруг да сработает…
И, к сожалению, очень часто современные курсы приводят вот именно к такому результату: человек не воспринимает компьютер как тупую числодробилку, которую он сам (при наличии достаточного времени, понятно) может разобрать на части снизу доверху и собрать обратно.
Для него выделение памяти — магия, сборка мусора — ещё большая магия, как хранятся и обрабатываются данные в используемых библиотеках — его не просто не интересует, он даже не догадывается, что ему может быть полезно этим поинтересоваться. Соответственно когда что-то не срабатывает — это не повод разобраться в том, что пошло не так, а повод отправиться на поиски бивней мамонта, которые магическим образом улучшат работу карбюратора.
К сожалению использование высокоуровневых языков поощряет формирование именно такого видение мира — потому их и опасно использовать для обучения программированию. При всём их практическом удобстве. Хорошие учителя могут эту проблему сделать не такой острой, но есть более простой способ: просто начать с какого-нибудь более низкоуровневого языка. Pascal, при всей своей архаичности, вполне годится: в нём нет никакой магии! Вы не поверите, но в Turbo Pascal User's Guide были не только подробно описаны функции Mark/Release но и было подробно описано — как устроена «куча» внутри, чем отличаются реализации «кучи» в версиях 5 и 6 и прочее.
Возможно, это просто мой pet peeve, но такая двойственность (с одной стороны, говорят о том, как важно быть логичным и прочее, а с другой, без оглядки используют такое расплывчатое понятие) выглядит очень странно.
Не вижу ничего странного. Отличить науку от лженауки зачастую не так-то просто — но, тем не менее, одно — приносит нам новые, улучшенные процессоры, увеличивает «удои» и прочее, а второе — приводит примерно вот к такому.eydemidov
09.07.2016 00:13> Вы действительно не видите разницы?
Разницу между чем и чем? Посмотрите сверху, там ещё один мой пост есть (над постом от DistortNeo) — я там как раз и попросил примеры кодера/программиста, чтобы понять, кто под ними подразумевался в данном конкретном случае, и разницу между ними.khim
09.07.2016 01:44Я сталкиваюсь (на собеседованиях) с кодерами постоянно, но так как моя задача — их отсеять, то я понятия не имею чем они занимаются там, куда их берут на работу.
Но разница между программистом и кодером — довольно простая: задача кодера — написать код, задача программиста — создать программу. Кажется, что это одно и то же? Нет, нифига.
Написать код — это как в известной притче: «Если достаточно долго месить чан с перловой кашей, в синтаксическом мусоре можно рано или поздно узреть лик Ларри Уолла». Есть задача, мы её решаем и если всё сделано «как написано», то… «я лично пришиваю пуговицы — к пуговицам претензии есть?»
А написать программу — это другое. У тебя есть задача и заказчику пофигу что у тебя там не работает — IndexDB, OpenCV или ASP.NET. По-фи-гу. Ему нужно чтобы программа работала.
Бич программирования — это пресловутые протекающие абстракции. В проекте, над которым я сейчас работаю — сотни миллионов строк. Я работаю над маленьким компонентом (где-то с полмиллиона строк), но баги, которые у нас «выстреливают» (в смысле — нам на них жалуются)… примерно в половине случаев — на самом деле они не у нас, а где-то в другом месте — и мне нужно понять (хотя бы примерно) — где (и кто за эту часть отвечает). Потому что багов быть не должно, а то, что они не у нас — не означает, что нам на них можно «забить».
Так вот без хотя бы примерного понимания того, как все эти бесконечные слои абстракций работают — я этого сделать не могу. А люди, освоившие «на специальных курсах visual, научившиеся расставлять формочки и прочее» — даже не предствляют что делать если у них возникла проблема из-за того, что где-то в огромном стеке технологий, которые они используют, случилась очередная «протечка» и «что-то пошло не так». Вернее «представляют» и «делают» — «месят чан с перловой кашей». При этом одна и та же ошибка «загоняться вглубь» множеством разных способов — но будет неизменно «всплывать», так как люди, которые с ней борются не понимают не только откуда она проистикает, но и не имеют представления о том, что ответ на этот вопрос вообще существует!
«Почему сервер иногда отвечает за две минуты вместо двух сукунд?» «А фиг его знает — но мы watchdog поставили и перезапускаем его, когда он начинает подтомаживать».
Какое-то время это работает, но когда количество костылей переваливает за критическую массу… про историю с Windows Longhorn — слышали? А ведь там кодеров участвовало не так и много в процессе. Большинство разработчиков в Microsoft — неплохие профессионалы.
webkumo
09.07.2016 02:06+2Вот так много слов и совсем нету смысла. Знаете что вы сказали? Что есть профессионалы и есть шарлатаны. Вот смысл вашего многословия.
Хотя я даже с этим не соглашусь — очень многие наработки алхимии легли в основу химии. Нет, ну правда. Люди накопили опыт, который потом удалось систематизировать. Не было бы опыта — и что бы химики систематизировали? Да если ещё и без помощи физиков?
Что там ваша бедная девочка с картинками — она хоть раз работала с таким классом задач? Ей помогали? Была ли достаточно дружелюбной атмосфера, чтобы она могла спросить сама? Нам ничего этого не известно. Интересно было бы уточнить у DistortNeo этот момент. Просто если «девочка студентка» впервые видит этот класс задач, а на её вопросы её посылают лесом — то она вполне естественно ничего не сделает. Это ж джун зелёнейший!
И вдруг появляются такие странные утверждения… джун имеет право не знать ни про выделение памяти ни про сборку мусора… первые полгода-год погружения в практические задачи. Вот чтобы вырасти из джуна (самое близкое к описываемому «кодеру») — да, требуется погружение, понимание и много чего ещё.
Использование высокоуровневых языков позволяет на стадии изучения алгоритмов игнорировать некоторые особенности реализации этих алгоритмов на исполняющей машине. А то, что после этого почему-то забывают людям дать остальные знания — язык-то точно не виноват. А низкоуровневые просто работают этаким «фильтром» — справится с концепциями и алгоритмами разом или нет… ну нет — значит «не программист».
PS иногда видел разделения программист/кодер в виде, присваивающем программисту менеджерские/аналитические/архитектурные задачи… видел даже экономические задачи реализации алгорима! Хотя программист, по большому счёту, менеджерскими и большей частью аналитических задач заниматься не должен. Т.е. проанализировать прикладную область, проанализировать инструментально-библиотечные возможности, безусловно, должен программист, а вот пообщаться с заказчиком и выяснить, а что же он хочет — это всё-таки задача аналитиков/менеджеров. Но некоторые почему-то накладывают на программиста умение договариваться с заказчиком…
PPS а вообще разделение программист/кодер появляется когда ну очень хочется почешить ЧСВ и под программиста закладывается то, чем пишущий по факту занимается.MacIn
09.07.2016 03:22+1джун имеет право не знать ни про выделение памяти ни про сборку мусора…
Серьезно? Можно мне другой глобус, пожалуйста?webkumo
09.07.2016 03:41-1Серьёзно. Другой глобус — это к Маску.
Вы забываете, что помимо языков с прямым управлением памяти бывают «managed» языки (java, javascript) и сессионные языки (php как минимум 4ая версия, более поздние не смотрел). Сессионным языкам, как можно логично предположить — болт положить на утечки, т.к. создать утечку, которая в пределах одной сессии сожрёт всю память — это надо очень постараться. Чуть ли не специально так писать придётся. В «managed» языках так же сложно писать так, что будут серьёзные утечки… Хотя на StackOverflow действительно реалистичная ситуация. Ну так она классическая «учебная».
В итоге получаем — знать по факту — не обязательно. Но только совсем-совсем зелёному (да не троллю! джуну!).
При дальнейшем развитии — ему придётся писать более сложные алгоритмы/обращаться к внешним ресурсам — вот здесь уже потребуется реальное понимание (а не то, что он вынес из ВУЗа/курсов), как это всё работает… он с этим должен будет разобраться (хотя и будет по прежнему джуном).MacIn
09.07.2016 03:49+1При чем здесь «есть другие языки»? Джун — это уровень квалификации — «начальный», т.е. человек без опыта, но с базовым набором знаний. Выделение памяти — в пределах первого курса любого ВУЗа. Если человек закончил ВУЗ по профилю и не знает про выделение памяти, то ему стоит выкинуть свой диплом. Если не учился и не знает, то он просто не обладает достаточной квалификацией, чтобы быть «джуном».
webkumo
09.07.2016 14:14-1А если забыл, ввиду того что не пользовался этим C/C++ с того самого первого курса?.. Возьмём тот же JS — там ведь вообще выделять по сути не требуется (точнее это легко можно упустить, т.к. язык не требует каких-либо действий кроме присвоения).
Ну и знает хоть что-то о выделении памяти (в рамках того самого первого курса) и сколько-нибудь достаточно понимает — вещи очень разные. Я имел ввиду больше 2ое.MacIn
09.07.2016 15:31А если забыл, ввиду того что не пользовался этим C/C++ с того самого первого курса?..
Это субъективно, конечно, но на мой взгляд, это некое базовое знание, примитив к тому же. Если отложить в сторону JS, то даже в той же Java понятно, что объект создается не из «пустоты». Более того, вопросы работы с памятью входят в экзамен на самый начальный сертификат.
Язык, которым мы пользуемся — это только инструмент, принцип работы кучи (условно) — это знание, которое не зависит от инструмента.
Ну и знает хоть что-то о выделении памяти (в рамках того самого первого курса) и сколько-нибудь достаточно понимает — вещи очень разные. Я имел ввиду больше 2ое.
Не знаю… нам давали это на первом курсе, в упрощенном виде (список свободных блоков, дробление, фрагментация и т.п.), но общее представление это дает всем — проще быть не может.
khim
09.07.2016 15:36точнее это легко можно упустить, т.к. язык не требует каких-либо действий кроме присвоения
В этом и проблема — легко упустить, а потому нужно постоянно об этом помнить. И тот факт, что явно освобождать память не требует не делает задачу проще — наоборот, это загоняет проблему «вглубь». Вам по прежнему нужно думать о том, чтобы все ссылки на более ненужные объекты обнулились, однако при этом у вас в коде даже нет «реперных точек», которые отмечают момент, где это происходит.
Ну и знает хоть что-то о выделении памяти (в рамках того самого первого курса) и сколько-нибудь достаточно понимает — вещи очень разные.
Конечно. Проблема в том что «практический подход» призывает к тому, чтобы просто не думать о том, что память — это вообще ограниченный ресурс. А результат — у меня телефон, которые в 1000 раз мощнее чем компьютер, на котором я впервые увидел электронную почту, не всегда позволяет мне написать письмо в 100 килобайт размером (нет, я всё понимаю: Unicode и всё такое… но тексты подобного размера я редактировал на компьютере MSX-2 с памятью, на минуточку, 128K и процессором 3.58MHz, а мой телефон с памятью в гиг и процессором в 2GHz этого не может — это вообще в какие ворота?).MacIn
09.07.2016 15:50Ага, еще забавно было видеть примеры в учебниках по программированию вида «создадим простейший редактор текста. Вот у нас строковая переменная, читаем в нее файл...». И возникает внезапный прикол, что во-первых эта программа отожрет памяти по размеру файла, при том, что мы видим в каждый момент времени только «окно», а во-вторых, будет доооолго открывать этот файл. При этом какой-нибудь Volkov Commander откроет и отредактирует тот же 1Гб файл в реальном режиме.
khim
09.07.2016 17:40При этом какой-нибудь Volkov Commander откроет и отредактирует тот же 1Гб файл в реальном режиме.
Не откроет — это вам не МироМир.
Но, кстати, прообраз того самого Volkov Commander'а очень хорошо показывает к чему приводит бездумное применение модных технологий.
Кокретнее — в его 5й версии. Правда началось это с 4'й (где появился NCZIP), но апофигей — это 5я.
Она в 20 раз больше (притом что новых фич появилась горстка), но вот как раз NCEDIT объёмом почти в 200K — это финиш.
Дело в том, что как и в предыдущих версиях редактор показывает надпись во время загрузки текста — ну чтобы пользователь понимал что происходит.
Однако в версии 5.0 этот редактор — отдельный файл почти в 200K размером. При этом файлы, которые он может редактировать — по прежнему не могут быть больше 64K (тогда это считалось нормальным… Turbo Pascal 5.x тоже не умеет файлы больше 64K редактировать, к примеру).
Вот кем надо быть, чтобы задизайнить систему, которая не сообщает о загрузке с диска файла в 200K, но потом показывает процесс загрузки файла размером не более 64K? С прогресс-баром и прочими прелестями?MacIn
09.07.2016 18:09Не откроет
Значит, я путаю с каким-то другим файловым менеджером, но не суть, я думаю, довод понятен: окно против целого блока.
Кокретнее — в его 5й версии. Правда началось это с 4'й (где появился NCZIP), но апофигей — это 5я.
Ага, это было печально, когда он перестал влезать на дискету. ЕМНИП, 5ю версию переписали на другом языке, поэтому она такая пухлая.
DistortNeo
09.07.2016 11:53+1Отвечаю про девочку-студентку. Цель заданий — избавиться от типичных ошибок джунов при работе с изображениями: они забывают про диапазон 0-255 и выход из него, иногда выходят за границы массива, в неправильном порядке обходят изображения (из-за чего падает скорость). Только после этого студентам можно ставить более-менее приличные задачи, имеющие хоть и небольшую, но практическую ценность.
Все студенты перед заданием получают теорию (что такое свёртка и как её считать), программу-болванку для работы с изображениями (загрузка и сохранение). Консультируем студентов с удовольствием. Дополнительных материалов (учебники, интернет) навалом. В чём проблема решить простую задачу? Но если человек не может хоть как-то решить даже простую задачу, то такой человек нам не нужен, и тратить своё время на него мы не видим смысла.webkumo
09.07.2016 15:22DistortNeo в такой ситуации проблема, скорее всего, в том, что девочка по сути не программист. Согласно тому, что вы описали здесь идёт простейшее непонимание принципов работы компьютерных систем. Т.е. это равносильно ситуации «гуманитарий поизучал курсы программирования». Отсутствие базовых знаний и понимания.
Это НЕ кодер. Это неспециалист.
И у неё выбор простой — или стать-таки специалистом (вполне возможно, что она это может), или отказаться от этой специальности и заняться чем-то более релевантным её знаниям/умениям. В виду калечности её знаний — пусть становления специалистом её будет крайне затруднён. Т.е. «кодера» мы тут не нашли.
vlad72 Вопрос не в уровне. Есть специалисты, есть неспециалисты. В текущей дискусси кодеры не появлись. И от методики может зависеть качество специалиста и процент выхода годного продукта (специалистов). Я не знаком с методиками, которые из любого человека сделают специалиста. Есть методики которые неспособны сделать специалистом.
PS возьмём простой пример (действительно простой, если знать как работает компьютер и как работает js… единственное но — нахождение проблемы требует некоторой усидчивости): есть проблема — после нажатия shift+а (русская) в некотором поле поле перестаёт принимать символы.
Можете описать примерный процесс поиска?
Уточню — библиотек и js-кода много и всё это свалено в кучу (там ещё и говнокод местами… в общем-то проблема как раз в куске такого «щастя» и нашлась). Я (плохо знакомый с кодом — 3ый месяц в проекте) потратил чуть больше 5 часов на эту (в общем-то простую, но нудную) задачу, джуны-мидлы более-мене знакомые с проектом не знали с какой стороны к ней подступиться. Впрочем и здесь надо уточнить — у меня, судя по всему, самый сильный скилл по вебу (хотя я себя позиционирую больше как бекэндера, хотя и умею фуллстек)vlad72
09.07.2016 15:50> Я не знаком с методиками, которые из любого человека сделают специалиста.
Но зато есть методики, как из потенциального специалиста сделать законченного неспециалиста ))
khim
09.07.2016 16:02В такой ситуации проблема, скорее всего, в том, что девочка по сути не программист. Согласно тому, что вы описали здесь идёт простейшее непонимание принципов работы компьютерных систем. Т.е. это равносильно ситуации «гуманитарий поизучал курсы программирования». Отсутствие базовых знаний и понимания.
Почему не специалист? Это — уровень 90% «разработчиков на 1С» и где-то половины «натягивателей шкурок на CMS». Они сами — считают себя программистами. Ну потому что программы-то они пишут :-)
Это НЕ кодер. Это неспециалист.
Есть специалисты, есть неспециалисты. В текущей дискусси кодеры не появлись.
А кто тогда появился? Как этих людей назвать? Они «что-то знают» про CSS, JS, HTML, пишут какой-то код, получают за это зарплату, некоторые работодатели, надо полагать, довольны (иначе они не приходили бы к нам на собеседования, а либо научились бы программировать, либо «переквалифицировались бы в управдомы»). Кто они? Как их назвать?
Можете описать примерный процесс поиска?
Ну как я могу описать то, чего я не делал? Понятно что чудес в мире не бывает, значит нажатие этого самого shift+а изменило что-то в документе. Либо DOM, либо состояние какой-нибудь JS переменной. То есть вначале нужно сравнить DOM «до» и «после» нажатия. Если он поменялся (скажем поле поменяло аттрибуты), то нужно смотреть — кто и когда и поменял, если нет — значит у нас где-то кто-то перехватывает event'ы и нужно искать — кто и где. Если вы за 5 часов проблему нашли, то, надо полагать в внутренности браузера не лазили, так что можно считать, что ошибок в реализации браузера нету и, скорее всего, кто-то где-то неправильно обрабатывает сообщения и, получив, «чужое» сообщение блокирует не то поле, которое хотел. Может страничка пытается сама поиск реализовать (чтобы по Ctrl+F не открывалось окошко поиска — это, конечно, перепутать Ctrl+F и Shift-А непросто… но я ещё и не то видел) или ещё чего-нибудь в этом же духе.
В общем не очень понятно — чего вы хотели увидеть… и не очень понятно почему джуниор должен в подобных местах «в ступор» впадать…
vlad72
09.07.2016 13:07+1>Знаете что вы сказали? Что есть профессионалы и есть шарлатаны. Вот смысл вашего многословия.
Вопрос состоит не в уровне развивающего программиста, а в том, что одна методика обучения готовит людей, готовых к развитию, а другая просто информированных на некоем уровне и теряющихся при новых для него проблемах.
VolCh
10.07.2016 12:26Я придерживаюсь версии, что «кодер» — это сленговое название техника-программиста по классификаторам профессий (выпускник техникума или колледжа), а «программист» — инженер-программист (выпускник вуза). Понятно, что некоторые выпускники вузов даже кодером работать не смогут, а кто-то и без формального образования как инженер большинство выпускников за пояс заткнёт, но в целом по квалификационным требованиям можно посмотреть чем отличается «кодер» от «программиста». Базовое же различие, по-моему, «кодер» решает технические задачи, а «программист» — производственные техническими средствами.
Vjatcheslav3345
09.07.2016 20:18А что именно (какой ньюанс) не понимала студентка и какими подходами Вы пользовались для объяснений?
DistortNeo
09.07.2016 20:38Я так и не понял, в чём была проблема.
На предложение показать проблему — ноутбук не с собой.
Ещё и ходила на занятия один раз через два.
arielf
07.07.2016 20:02Ремесло — Это написание отчётов в 1C, а создание системы управления грузовыми перевозками, авиарейсами или производством — сложная инженерная работа в которой иной раз изобретаются новые концепции и парадигмы программирования.
Symphel
08.07.2016 08:44+1Написание отчётов в 1C вполне может потребовать труд нескольких человек, если отчет строится неприлично долго и нужно оптимизировать обработку данных. Управления грузовыми перевозками/производством некоторые умельцы решают таблицей и парой формочек в каком-нибудь Oracle Forms. Вопрос масштаба и конкретной задачи. И то, и другое — это программирование.
Что вы пытаетесь доказать? Что есть программисты и Программисты? Вы из этих?
DrPass
08.07.2016 12:31+2Вообще, я с вами не соглашусь. Ремесло от творчества в программировании отличается не сутью задачи, а тем, сколько раз вы её уже решали. Делая свой первый отчет в 1С, вы точно так же первопроходец. Делая стопятидесятый, вы ремесленник. Делая свою первую систему логистики, вы тоже изучаете для себя новую отрасль, собираете материалы по автоматизации (если вам повезло работать «самостоятельным» программистом, а не винтиком большой девелоперской машины) и т.д.
А для следующего клиента вы уже будете идти знакомым путем, и это уже тоже будет ремесло.
VolCh
08.07.2016 08:15+2Не путайте инженерное дело и ремесло. А инженерное дело — отрасль научно-технической деятельности.
andreymal
07.07.2016 17:21+3Совсем не обязательно ставить целью результат, имеющий какую-то практическую ценность. Плюс к этому теория без применения на практике очень тяжело запоминается, а если и запоминается, то быстро улетучивается. А вот если в качестве «результата» поставить, например, решалку квадратных уравнений (с комплексными числами и вырожденными случаями), крестики-нолики или морской бой (возможно, с последующим добавлением сетевой игры), то по идее обучение должно стать проще и эффективнее, ибо теория сразу применяется на практике. А в связи с отсутствием практической ценности (кроме собственно обучения) и относительной простотой задачек всё выкинуть и переписать с нуля, набравшись опыта, будет совсем не жалко. И я сам так изучаю новые языки и технологии)
DistortNeo
07.07.2016 21:04+1Ну да, у меня сначала был тетрис, потом домино (компьютер меня даже обыгрывал), потом творческий подход к решению задач по обработке изображений в университете (дано задание, решать можно любыми средствами), затем — полноценный бот для онлайн-игры, имеющий сервер обновления и около 50-100 пользователей, ну и потом просто работа.
Source
09.07.2016 02:10Для новичков как раз нужны книги для новичков («за 21 день», «на примерах» и т.д.).
Сложно представить, что кто-то может научиться программировать по толстому учебнику, приправив его ещё чтением стандарта и справочника по библиотеке.
Имхо, так можно учить 3-й, 4-й язык (я сам так C# когда-то давно изучал по 2 книгам Шилдта + стандарт), но не первый.eydemidov
09.07.2016 02:57+1С толстыми книгами есть другая проблема — они могут пытаться быть настолько всеобъемлющими, что хорошая их часть — банальщина и «из пустого в порожнее».
Мне вот понравилась книга «Core Java for the Impatient», например. Я не могу адекватно оценить т.к. много не работал (пока) с Java и многого не знаю, но подобное выглядит гораздо лучше, чем несколько книг от того же автора, где всё разжёвывают с самых нулей.Source
09.07.2016 12:36Это тоже. Когда уже знаешь несколько языков, наступает момент, когда читать в очередной раз про float vs double или про видимость методов и т.д. становится невыносимо скучно )
Серия «для нетерпеливых» уже лучше, но если оценивать «Scala for the Impatient», которую я недавно читал, то там тоже банальщины выше крыши.
Впрочем, есть и более хардкорные способы изучения, например: Learn X in Y minutes + документация по стандартной библиотеке (читать не целиком, а по мере необходимости).
Kate_Hamster
07.07.2016 12:06+3Согласна с автором, Си очень удобный язык для изучения азов программирования, правда нам в универе давали сначала функциональный CAML, а потом уже к Си переходили. Мотивировалось это тем, что большинство студентов до универа программированием вообще не занимались и если им сразу дать Си, то ничего компилироваться не будет. Не знаю, насколько верно это утверждение, правда.
ainoneko
08.07.2016 12:37Как он может быть удобным, если даже для «Hello, World!»-программы надо написать (а преподавателю объяснять (обычно словами «Так надо. Потом поймёте.»)) кучу неочевидных (а для начинающего — неестественных) вещей?
Kate_Hamster
08.07.2016 14:46+2Так на любом языке для «Hello, World!» нужно программный код писать. А удобство Си в том, что на основе его синтаксиса построен синтаксис огромного количества языков программирования. Плюс, как уже говорилось в статье, в языке достаточно немного основных ключевых слов, но при этом на нем можно написать много чего благодаря множеству уже существующих библиотек и системных функций.
DrPass
08.07.2016 15:08> но при этом на нем можно написать много чего благодаря множеству уже существующих библиотек и системных функций.
Ага, попробуйте на C заменить в строке все вхождения одной подстроки на другую подстроку произвольной длины :)
dns78
08.07.2016 15:16Это не сложнее, чем в любом другом языке. Просто берете что-нибудь вроде https://github.com/stephenmathieson/str-replace.c и пользуетесь.
DrPass
08.07.2016 15:25Неа, в том-то и дело, что «в любом другом языке» (ну, не в любом, конечно, но в подавляющем большинстве используемых ныне) эта типовая задача, и куча других типовых задач решаются стандартными библиотеками. А программист на С вынужден или писать велосипед или искать чужие велосипеды, к тому же тратить время на выяснение, можно ли чужому велосипеду доверять.
dns78
08.07.2016 15:32+1Ну, блин. Доверять чему-то придется. На стадии прототипа или учебной задачи можно доверять вообще всему, а нервничать о производительности/корректности опосля.
У меня вот недоверие к пресловутым стандартным библиотекам. Покажите мне, как на этих самых языках с библиотеками решить весьма тривиальную задачу — декомпозиция/нормализация utf-8 строки с выхлопом опять же в utf-8 — чтобы идентично работало, например, в java, c++, as3, js. Т. е. чтобы строки на естественном языке, обработанные в совершенно разных средах, можно было корректно сравнивать, считать хеши от них и тд.DrPass
08.07.2016 15:58> чтобы идентично работало, например, в java, c++, as3, js
Это ж задача совсем другого плана. Примерно как подружить между собой весь мир, и чтобы никто не воевал :) В случае одной платформы стандартным библиотекам всё-таки больше доверия, т.к. они потому и стандартные, что кто-то ответственный, наверняка понимающий, умный, справедливый, мудрый (надеюсь, ребята из Комитетов стандартизации меня сейчас читают) их одобрил.dns78
08.07.2016 16:09Дак нет, того же плана :) Того плана, что даже библиотеки для работы со строками довольно унылые, и в случае любого чиха приходится садиться на велосипед. Того плана, что нет общего стандарта ни на эти вот самые строки, ни на функционал библиотек — покамест все отдано на реализацию саппортерам конкретных языков.
Ладно, сие не есть проблема, реально требующая обсуждения :)khim
08.07.2016 19:11+1Ладно, сие не есть проблема, реально требующая обсуждения :)
В том-то и дело, что это — и есть центральная проблема, которую мы тут обсуждаем.
Дело в том, что замена в строке на подстроки на подстроку другого размера — это не сложная, а очень сложная задача. Как любая банальность эта — тоже обсосана Джоелем.
Соответственно все языки делятся на два класса:
1. Языки в которых очевидно, что это — сложная задача (C — один из них).
2. Языки в которых прилагаются неимоверные усилия к тому, чтобы сделать вид что это — простая задача.
Так вот: человека, который, этого не понимает, по большому счёту, программистом — назвать нельзя. Ибо он не понимает по какому минному полю он ходит. Он может быть художником, архитектором или даже говнокодером, но это — не программист! У него нет в руках миноискателя, который «звенит» возле проблемых участков кода! Он может реагировать на разрывабщиеся под ногами мины — но только наступая на них.
Означает ли это, что C — обязателен в программе обучения? Нет, конечно, какой-нибудь Pascal демонстрирует это не менее выпукло. А вот в «большинстве используемых ныне» языков — это неочевидно. И это — большая трагедия.
Человек, который этого не осознал и не прочувствовал может сколь угодно хорошо рассуждать на тему всяких алгоритмов, но у него нет понимания того, что с этими чёртовыми O(N), O(N log N) и O(N2) он всречается постоянно, на каждом шагу, при написании почти любой строчки кода!
А без этого понимания — нет хорошего программиста.
DistortNeo
08.07.2016 21:13Начинающий программист должен писать велосипеды для самообучения.
Понятно, что в продакшене нужно использовать готовые проверенные решения, но нет ничего хуже использования готовых решений без понимания, как они устроены изнутри.
MacIn
08.07.2016 15:22Так на любом языке для «Hello, World!» нужно программный код писать
Не, человек сказал «кучу неочевидных вещей», а не «код».
Например, чтобы написать HW на Quick Basic, нужно ввести ровно одну строку:
PRINT «Hello world!»
И все. И объяснить начинающему, что это, несложно: вот оператор вывода, вот текст, который мы выводим.
Возьмем Си:
#include <stdio.h>
int main(){
printf('Hello world!\r\n');
return 0;
};
Здесь уже сложнее: это потом, когда ты продвинулся, ты понимаешь, что инклюд позволяет тебе связать твой код с библиотекой, но изначально, для новичка — это ненужное, вспомогательное действие. Лишнее на этом этапе обучения.
Потом — зачем нам нужна «главная» функция, почему и кому она возвращает результат, почему вывод сделан вот так, и почему перевод строки выглядит вот так…
В общем — много мишуры, которая при росте размера и сложности программы станет просто «погрешностью округления», но для новичка оно совсем лишнее и только путает.
Это я не к холивору, просто пытаюсь на пальцах показать разницу для новичков (ну, раз уж о HW речь зашла).michael_vostrikov
08.07.2016 19:28Выскажусь с позиции такого новичка. На первом курсе мы изучали одновременно C++ и Pascal, до этого я знал только Visual Basic на очень базовом уровне. Не было никаких проблем понять, что include нужен для подключения функции printf(), не только у меня, но и у многих других. Перевод строки в первых программах особо и не нужен, но после объяснения тоже все понятно — курсор в начало / курсор вниз. Писали void main(), главная функция — точка начала программы. У всего есть понятная причина, никаких магических конструкций, которые работают сами по себе.
Да и с Паскалем была прямая аналогия: include — uses, printf — write/writeln. begin/end — {} (только слова набирать дольше и опечатки в них иногда делаешь).MacIn
08.07.2016 19:39до этого я знал только Visual Basic на очень базовом уровне
То-есть та самая начальная подготовка уже была, о чем я и написал.
но после объяснения тоже все понятно — курсор в начало / курсор вниз
Я не говорил, что «перевод строки» — непонятная хрень, я говорил о другом.
Писали void main(), главная функция — точка начала программы
А почему у программы должна быть точка начала, почему начало в виде функции?
Вот в примере на Бейсике все понятно: начался лист — началась программа. И так далее.
Вы идете все по тому же полю: "это можно понять, если приложить немного усилий". Я не говорю о том, что это дико непонятная вещь; я говорю о том, что это лишнее и мешает понять суть.michael_vostrikov
08.07.2016 20:20начался лист — началась программа
А потом в середине листа встречается объявление функции и становится очень непонятно, почему ее операторы не исполняются, ведь мы уже привыкли, что программа это лист.
А почему у программы должна быть точка начала, почему начало в виде функции
Потому что у всего есть начало и конец, программа разделяется на функции, начало и конец программы это главная функция. Я о том, что если есть простая причина почему надо делать какие-то действия, то это более понятно, чем пример и без действий и без объяснений, который просто почему-то работает. Мне кажется, это не лишнее, это и есть та суть, которую нужно понять — как работает программа.
Впрочем, может я и не прав, никогда не обучал программированию новичков.MacIn
08.07.2016 23:40А потом в середине листа встречается объявление функции и становится очень непонятно, почему ее операторы не исполняются, ведь мы уже привыкли, что программа это лист.
Во-первых, понятно — это отдельная поименованная область. Как текст/статья в рамке/блок в блок-схеме.
Во-вторых, при обучении элементарщине user defined функции не используются, они описываются позже.
В-третьих, отдельный модуль.
Я о том, что если есть простая причина почему надо делать какие-то действия, то это более понятно
А если нет никаких причин делать что-то ради того чтобы делать, еще лучше.
Мне кажется, это не лишнее, это и есть та суть, которую нужно понять — как работает программа.
Мы о разных стадиях говорим. Я имел дело с людьми, которые не знали совсем ничего. Такому ты объясняешь императивный принцип: вот твои действия: первое, второе, третье. Выполняются одно за одним, именно в таком порядке, никак иначе. Вот ветвление, вот цикл.
Потом, потом, уже идет «вот это повторяется, мы выделим это, назовем и вызовем. Это функция/подпрограмма».
Вот представьте, что вы объясняете по блок-схеме: здесь действия в чистом виде, никаких побочных объявлений, описаний, включений и пр. Чем лучше блок-схема отражается на язык, тем лучше для новичка.
Или тот же непопулярный нынче алгоритмический язык/мнемокод — описывает чисто алгоритм, используя базовые конструкции и никакой побочки.
ru_vlad
07.07.2016 12:06+9Может скажу банальность, но язык программирования это прежде всего «инструмент», а как известно прежде чем с ним работать (изучать) надо знать как его держать в руках. Моё мнение, начало это Алгоритм! Надо научиться алгоритмически мыслить, строить цепочки связей (команд) и видить цель.
Пусть меня закидают «тапками» но моё мнение алгоритмизацию лучше начинать с Паскаля. Как учебный язык нулевого уровня ему нет равных. Сам преподаю (уже 25 лет) и вижу что мода приходит и уходит, а классика остается.arielf
07.07.2016 15:17-3Возможно. Вы представляете немного иной подход — начинающийся не с машины, а с алгоритмов. Но тогда, наверное, лучше взять Modula или Oberon того же Никлауса Вирта, как более прогрессивные языки.
ru_vlad
07.07.2016 15:54Если все же вспомнить слова Вирта (отца Паскаля, Модулы и Оберона ;) ) когда его спросили какой язык программирования он считает наиболее подходящий для обучения, он ответил Паскаль как наиболее приближенный к человеческому :)
Да согласен, для студентов что направление ИТ учить надо с классики, С потом уже все остальное, НО для первоначального (нулевого) обучения (школьники) предпочтителен Паскаль.
Например, первые алгоритмические конструкции циклов (Пока/While, До/Until, Для/For) наиболее понятны именно здесь.
НО опять, на вкус и цвет, все фломастеры разные, сколько людей столько и мнений :)
Ваш покорный слуга основывается своём скромном мнении и опыте (25 лет пед работы ;) ) :)
k12th
07.07.2016 18:54+2А вы пробовали учить чему-то другому? Не оберону/модуле, а, скажем, Scheme, Python?
ru_vlad
07.07.2016 19:43+1На Питоне пробовал.
Но сразу говорю, средние и менее ученики взвыли :) Питон очень не плох для обучения, но (да опять НО ;) ) только в том случае если они понимают уже структуру алгоритма, То есть знают какому блоку (циклу или ветвлению) что принадлежит, а выделения программного блока отступами для них вообще кошмар, в Паскале, Си и прочих, программные скобки физически видны. С этого как раз и начинается практика, учу выделять блоки, что бы знали что кому принадлежит.arielf
07.07.2016 20:05+1Space — символы как часть синтаксиса языка была на мой взгляд очень глупой идеей. По этой причине его и не люблю.
Vjatcheslav3345
07.07.2016 21:38А не пробовали ли вы объяснять, что выделение отступами логических блоков им, ученикам, прекрасно знакомо на примере многоуровневых списков, которые они легко, не задумываясь, клепают в своих рефератах/курсовых:
А)
Б)
С)
1.
2.
- - 3.
И вообще, какими теориями и приемами, изобретенными великими педагогами и методистами, преподавателями компьютерной грамотности (Ушинский, Ершов, Макаренко и др.) Вы пользовались в работе?
Отступы в списке выше нормально не отображаются, но идея должна быть ясна...michael_vostrikov
08.07.2016 06:47Если бы мне в школе про списки начали говорить, я бы не понял еще больше.
— Отступы в списке можно сделать любого уровня, а не ровно 4 пробела, длина отступов на смысл не влияет.
— Отступы делаются для визуального разделения, а не для логического. Для логического как раз используются цифры и буквы.
— В списках нет циклов.
Я питон почти не знаю, мы в школе VB изучали, но когда начало и конец блока чем-то обозначены это более понятно.
ZaEzzz
08.07.2016 12:37Не все с вами согласятся. Если бы мне в школе преподавали питон, я бы сразу понял эту абстракцию.
— В питоне тоже не нужно делать ровно 4 пробела, можно и табуляцией это делать.
— Отступы делаются для выделения логического разделения, иначе список может читаться так же как постом выше, где парсер сожрал список — тружно понять где какой уровень и что за чем идет.
— Вы не представляете циклы в списках, а я представляю. Если список является пошаговым набором инструкций, то цикл в нем может быть реализован в таком виде: «Шаги А.4.1 — А.4.8 повторять до получения результата, но не более 8 раз».
В школе изучал QBasic и мне никто не говорил, что надо делать отступы — я их сам машинально начал делать для выделения логических блоков и повышения читаемости кода.Vjatcheslav3345
09.07.2016 20:55"— В списках нет циклов."
Если использовать ссылки на пункты то циклы появятся: "п. 3567. Заявителю при подаче заявления… повторить последовательно, в порядке возрастания номеров пунктов, 567886543 раз п. 700-3576"; появятся условия — "п. 766544321. ЕСЛИ заявитель соответствует пп. 788765 п. 765 раздела А Критериев, заявитель [исполнитель алгоритма] обязан произвести процедуру сертификации (см. п. 000-8765325799ф, раздела 765-87-у-7654н-123н, приложения 124-987-543-НКАРОЛ- 14986- 14Б:6Э Порядка обязательной сертификации заявителей...), если заявитель не соответствует ...".
На таких списках можно даже ассемблер разъяснить, объяснив, что метка в ассемблере — это аналог такой вот ссылки на нужное место ф формальном документе или списке из этого документа.michael_vostrikov
10.07.2016 00:26Это не цикл, а goto. С пониманием goto проблем обычно и нет. А сама инструкция «перейти наверх на пункт такой-то» — это и есть понятное обозначение конца блока, о чем я и говорил.
Цикл со счетчиком в виде списка на бумаге сделать не получится. Можно записать оператор словами, но если не знать как он работает, то будет непонятно.
Скрытый текстМне например сначала казалось, что словом for задается диапазон — «для» значений переменной i от A до B делать то-то (то есть как будтоif (i >= A && i <= B)). При чтении обычного списка с листа оно примерно так и воспринимается, потому что это декларативное описание.ZaEzzz
10.07.2016 22:06Для вас цикл — это не goto, но тут я с вами не согласен.
Я бы сказал, что пусть первым в меня кинет камень тот, кто скажет что с помощью goto нельзя организовать цикл.
P.S. И цикл со счетчиком на бумаге пишется на раз.michael_vostrikov
10.07.2016 23:14Я не говорил, что нельзя. Я сказал, что это не одно и то же, и воспринимаются они по-разному.
Впрочем, это уже оффтоп, я изначально говорил о том, что новичкам понятнее, когда границы блока явно обозначены, а не зависят от количества невидимых символов.
ZaEzzz
10.07.2016 22:01Вы говорите больше о программировании на списках, а я говорю о том, что списки вполне нормально соотносятся с логикой визуальных отступов.
Не путайте теплое с мягким.
arielf
08.07.2016 10:26Отступы в списке выше нормально не отображаются
Вот как бы и я о чём.
gaki
08.07.2016 11:22От отступов в Питоне поначалу действительно колбасит, но довольно быстро привыкаешь и даже начинаешь получать удовольствие. У меня поначалу больше проблем вызывало то, что зачастую непонятно, где ты используешь ссылку на объект, а где — копию.
ru_vlad
08.07.2016 13:24Милый вы мой :) что вы говорите, 7-8 и даже 9 класс не то что нормальные рефераты сделать и оформить не могут, а об многоуровневых списках вообще молчу :)
Кстати пример не очень удачный. Как раз Паскаль в этом отношении с его Begin и end наиболее понятен.
По теории педагогики ;) это не ко мне :) пед образования не имею :) зато в активе военное (Можайка) и инженерное (программист) :)
А прием очень простой, ты должен объяснить так что бы любой человек смог понять :) ну и конечно армейский принцип «делай как я» :)arielf
08.07.2016 18:38Ну я всё же не про школьников писал, а про студентов или образованных самоучек (естественные или инженерные направления). Школьники или 'нулевые' ученики — вообще отдельный разговор, я, например, не очень знаю, как учить человека с полного нуля. На мой взгляд всё же должна сначала стихийно накопиться некая критическая масса знаний, чтобы было общее представление. И у школьников программирование обычно как обязаловка, мало связанная с их желаниями.
Vjatcheslav3345
11.07.2016 09:14Армейский принцип «делай как я»:
Познакомьте из с TeX, LaTex, потом с OMdoc — только осторожно, не залезая в дебри — для этого уже есть книжка "Сверстай диплом красиво: LaTeX за три дня" (http://www.stolyarov.info/books/latex3days). Тем кто не одолеет его — покажите руководства (прямо ткните в страницы по текстовым стилям) по OOWriter, онлайн документацию по MS Word.
Vjatcheslav3345
12.07.2016 08:58Text Encoding Initiative (TEI) — с ним можно познакомить гуманитариев — это их специализированный инструмент.
gaki
08.07.2016 06:35Разве на Питоне нельзя, при желании, писать, как на Паскале?
(Надо ли на Питоне писать, как на Паскале — другой вопрос.)khim
08.07.2016 19:14На Питоне нельзя писать как на Паскале. Вот на C — можно, а на Питоне — нет. У него просто нет базовых структур данных со сложность O(1).
Это как заниматься гимнастикой на батуте: тренированный атлет это сделать может, но новичка этому учить — боже упаси. Лучше уж твёрдый пол и устройчиво стоящие на нём снаряды…gaki
08.07.2016 19:20> У него просто нет базовых структур данных со сложность O(1).
Эмм… щито?khim
08.07.2016 20:31Нет вообще ничего, что работало бы за константное время. Два числа нельзя за константное время сложить! Или присвоить!
Потому что всё-на-свете хранится в ассоциативных массивах, которые расширяются по мере необходимости. А числа в BigNumы превращаются, если нужно. Это удобно, спору нет — но это же и обозначает, что вы никогда ни в чём можете быть уверены.
Для человека, которые уже имеет представление об алгоритмах — это не проблема, но когда вы пытаетесь рассказать о том что такое «сложность вычислений» и «потребление памяти» — это ужасно. У человека возникает чёткое ощущение, что преподаватель «чего-то недоговаривает».gaki
11.07.2016 12:22Признаться, всё ещё не улавливаю сути вашего педагогического посыла. Вот, например, человек пишет о внутреннем представлении целых чисел в Питоне: http://www.laurentluce.com/posts/python-integer-objects-implementation/
Т. е., может так получиться, что я сложил два числа, и результат сохранится в уже выделенном блоке памяти. А может так, что интерпретатор должен будет выделять новый блок, и это займёт больше времени — вы об этом?khim
12.07.2016 13:34Не только об этом. Там в совокупности много чего набирается: обращение к переменным идёт через хеш (у нас же интерпретируемый язык, причём, в отличие от древноего BASIC'а переменных не фиксированное число, а сколько угодно), для части переменных есть отдельные оптимизации и т.д. и т.п. Простейший пример:
$ python3 Python 3.4.3 (default, Oct 14 2015, 20:28:29) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> a = 100 >>> b = 100 >>> a is b True >>> a = 1000 >>> b = 1000 >>> a is b False
Как? Почему? За что?
Туева хуча «протекающих» абстракций! Да, обычно они вас не беспокоят, а если вдруг что-то случится — вы знаете где и что искать. Но это вы — человек с опытом работы и знающий где что происходит.
А если человек только учится? И только лишь пытается разобраться в том, как работает инструмент, который ему дали?
Скорее всего решит «это магия, иногда она срабатывает, иногда нет, что ж тут такого»… а что будет, если потом в реальной работе магия не сработает?gaki
12.07.2016 16:46Если развить вашу мысль, разве не получится, что магия вообще везде, и иногда работает так, а иногда — иначе? Сложить два числа хоть на Си, хоть на Паскале, хоть на Ассемблере за константное время? Ну разве что в ОС жёсткого реального времени или на голом железе (очень распространённые среды для обучения начинающих программистов, ага). А вот от такой, к примеру, магии и вообще ничего не спасёт: http://stackoverflow.com/questions/11227809/why-is-it-faster-to-process-a-sorted-array-than-an-unsorted-array
DrPass
12.07.2016 16:56> Сложить два числа хоть на Си, хоть на Паскале, хоть на Ассемблере за константное время?
Сложение, это же не обработка строки. В любой ОС это будет константное значение. Процессор не переключит контекст, пока он выполняет по сути атомарную операцию сложения.
> А вот от такой, к примеру, магии и вообще ничего не спасёт
Это ж не магия, а дюже умный современный процессорkhim
12.07.2016 17:00Процессор не переключит контекст, пока он выполняет по сути атомарную операцию сложения.
А кто его остановит? Вопрос в частоте, конечно.
gaki
12.07.2016 17:03> Процессор не переключит контекст
Пацаны, написавшие InterlockedIncrement и прочие наборы атомарных арифметических функций, опять не знали?
> Это ж не магия, а дюже умный современный процессор
И? В чём принципиальная разница, кто виноват и что делать?khim
12.07.2016 17:08И? В чём принципиальная разница, кто виноват и что делать?
Принципиальная разница в том, что «магия» — это что-то непознанное и постижимое, а процессор — это что-то, сделанное людьми и людьми же обслуживаемое.
Если уж совсем без магии хочется — возьмите эмулятор Atari 2600. Отличная вещь: без вских OS, но главное — видопамять на одну строку и отсутствие прерываний. То есть вам нужно за время показа одной строки выполнить определённый кусочек программы, который породит вам следующую строку. С точностью до такта!
И никакой магии.
DrPass
12.07.2016 17:28> Пацаны, написавшие InterlockedIncrement
Пацаны знали, но писали его не для тех данных, которые целиком вмещаются в регистр процессора. По крайней мере, если речь идет об x86.
> И? В чём принципиальная разница, кто виноват и что делать?
Принципиальная разница в том, что поведение процессора логично и ожидаемо.gaki
12.07.2016 17:46> которые целиком вмещаются в регистр процессора
Лолшто? 32-битный аргумент функции InterlockedIncrement не вмещается целиком в регистр процессора? При том что для х86 эти регистры стали 32-битными начиная, кажется, с i386?DrPass
12.07.2016 17:51Зря лолштокаете. В самой документации по Interlocked-функциям написано, что арифметические операции с 32-битными числами на 32-битных ОС являются атомарными :)
gaki
12.07.2016 18:06Ссылку, сестра, ссылку!
DrPass
12.07.2016 18:19Ну вот, например:
https://msdn.microsoft.com/en-us/library/ms684122.aspx
А что, у вас есть сомнения, что 32-битный процессор в состоянии атомарно обработать 32-битное число? Ему обязательно дробить на микрооперации действие, которое делается сумматором из полусотни вентилей?khim
12.07.2016 18:35Ему обязательно дробить на микрооперации действие, которое делается сумматором из полусотни вентилей?
Нет, конечно. Но ему обязательно нужно будет разбить одну инструкцию как минимум на три: чтение из памяти, модификация данных и запись. И тут полусотней вентилей никак не обойтись: сколько блоков участвует в «походе в оперативную память» на современном CPU даже представить себе страшно!
gaki
12.07.2016 18:39Слуште, ну не надо так пугать меня на старости лет! Вы сами-то пробовали читать, что там написано? «Приложения должны синхронизировать доступ к переменным… Приложения должны обеспечивать атомарность операций...» И далее: «Простые операции чтения и записи на выровненные 32-битные переменные атомарны, т. е. не возникнет ситуации, когда только часть переменной была обновлена, все биты обновляются атомарно. Однако синхронизация доступа не гарантируется. (...)»
> А что, у вас есть сомнения…
Не сомнения у меня есть, а твёрдая уверенность. Вот вам пример из Рихтера. Инкрементируем переменную в одном потоке:
MOV EAX, [g_x]; значение из g_x помещается в регистр
INC EAX; значение регистра увеличивается на 1
MOV [g_x], EAX; значение из регистра помещается обратно в g_x
В двух потоках по-очереди:
MOV EAX, [g_x]; поток 1 в регистр помещается 0
INC EAX; поток 1. значение регистра увеличивается на 1
MOV [g_x], EAX; поток 1. значение 1 помещается в g_x
MOV EAX, [g_x]; поток 2. в регистр помещается 1
INC EAX; поток 2. значение регистра увеличивается до 2
MOV [g_x], EAX; поток 2. значение 2 помещается в g_x
В двух потоках параллельно:
MOV EAX, [g_x]; поток 1. в регистр помещается 0
INC EAX; поток 1. значение регистра увеличивается на 1
MOV EAX, [g_x]; поток 2 в регистр помещается 0
INC EAX; поток 2. значение регистра увеличивается на 1
MOV [g_x], EAX; поток 2. значение 1 помещается в g_x
MOV [g_x], EAX; поток 1. значение 1 помещается в g_x
Это лишь один из многих вариантов, ассемблерные инструкции могут быть перетасованы и любым другим образом. Ну вы чего, в самом деле…
khim
12.07.2016 19:25Не нужно ничего перетасовывать даже. Банальный «inc [g_x]» не гарантирует атомарности если не используется префикс LOCK". А какой, собственно, в этом префиксе был бы смысл, если бы всё и так всегда атомарно работало бы?
Кстати скорость работы инструкций «inc [g_x]» и «lock inc [g_x]» очень заметно отличается. В несколько раз.DistortNeo
12.07.2016 21:28Ага, я даже пытался замерить это время: из нескольких потоков инкрементил одну и ту же области памяти и считал сумму за секунду.
У меня получилось 175M инкрементов в секунду при одном потоке и всего 47M при 2 и большем числе потоков. Получается, что при инкременте в 4 потока каждый из потоков выполняет инкремент всего 12M раз. Т.е. когда к памяти имеет доступ один поток, получается около 23 тактов на операцию, а когда несколько (например, 4), то значение увеличивается до 300-350 тактов. Для сравнения: простой инкремент — 1-2 такта.
DistortNeo
12.07.2016 21:16Корни проблем неправильного понимания атомарности растут со старых архитектур. Когда у нас процессор (ядро) был один, то да, любая операция, которая выражалась одной ассемблерной командой, была атомарна. Потому что никто параллельно не мог работать с той же областью памяти. А вот действия, состоящие из несколько команд, могли быть прерваны посередине.
В случае многопроцессорных систем для обеспечения атомарности стало необходимо также блокировать совместный доступ к памяти. Поэтому Interlocked команды используются даже если аргумент влезает в регистр процессора.khim
12.07.2016 21:34+1Корни неправильного понимания атомарности растут из неправильного понимания атомарности. Да, когда у вас система достаточно простая, то всё работает так, как вы описываете. На том же Atari 2600 просто некому «испортить малину». Но уже на первом IBM PC (а это, так, на минуточку, 81й год) есть DMA и 8087й сопроцессор, который, на минуточку, ходит в память параллельно и независимо от основного процессора! И там уже можно испытать все «прелести» неатомарности операции
incи нарушения правил алиасинга (а вы как думали — откуда они в C/C++ взялись? вот именно отсюда… не конкретно от 8087го, конечно, а в принципе — от архитектур где CPU и FPU независимо ходят в память).DrPass
14.07.2016 15:43Ну не преувеличивайте :) Ни DMA, ни сопроцессор, не смогут захватить шину независимо от основного процессора у IBM PC. Это «мнимый» параллелизм. Только тогда, когда он её сам готов отдать. В случае DMA — даст контроллеру команду на загрузку данных, в случае сопроцессора — когда он сам выберет из очереди инструкцию Fxxxx. Аппаратные прерывания? Тоже нет, у 8086 перед переходом по вектору прерывания сначала целиком завершается текущая инструкция.
Опять же таки, что касается атомарности, если рассматривать многопоточную работу, да еще когда несколько потоков лезут к общим данным в оперативной памяти, то естественно, вы правы. Но сама операция сложения действительно атомарна :) Более того, если вы попробуете сложить два целых числа в простом примере, вы увидите, что компилятор вам сделает сложение регистр-регистр, а не будет тянуть их из памяти. Так что не всё так сложно, как вы пишите.khim
14.07.2016 19:21Только тогда, когда он её сам готов отдать.
Проблема в том, что он вполне себе «готов её отдать» посреди одной инструкции — а иначе префикс LOCK смысла бы не имел. А он, напоминаю, в 8086 уже был.
В случае DMA — даст контроллеру команду на загрузку данных, в случае сопроцессора — когда он сам выберет из очереди инструкцию Fxxxx.
Записать в память сопроцессор осуществляет не тогда, когда он «выберет из очереди инструкцию», а когда у него данные появятся, что, опять-таки может произойти непонятно когда. Опять-таки: если бы было не так, то команда WAIT была бы не нужна — а она тоже в 8086м появилась.
Описанную вами «сферическую» атомарность невозможно увидеть и ощутить без обращения в память, а как только мы туда начинаем обращаться — у нас начинаются гонки. И, собственно, тот факт что средства для борьбы с ними появились в 8086м процессоре — это очень такой толстый намёк.
Не понимаю с чем вы спорите и зачем.DrPass
15.07.2016 10:45> если бы было не так, то команда WAIT была бы не нужна
Команда WAIT же не для того, чтобы гарантировать «атомарность» работы операций процессора. Она для того, чтобы корректно обработать результат работы FPU.
> Не понимаю с чем вы спорите и зачем.
Я ни с чем оне спорю, я просто объясняю свою позицию, что неоднозначности с синхронизацией в работе процессора не существенны для обучения на императивных языках, где действительно время и порядок выполнения операций прогнозируемы. С ними можно столкнуться в специальных случаях, а не в работе учебных приложений. А как работает IBM PC, я, в общем-то, знаю. Примерно на таком уровне:
http://zx-pk.ru/threads/22102-pk-poisk-adapter-som-portov.htmlkhim
15.07.2016 20:33Команда WAIT же не для того, чтобы гарантировать «атомарность» работы операций процессора. Она для того, чтобы корректно обработать результат работы FPU.
Команда WAIT нужна для того, чтобы получить сигнал «всё, я отстрелялся». Так как 8087 сам, независимо ходит в память, то она нужна, в частности, для того, чтобы «иметь право» обратится к памяти, в которую пишет FPU. В частности если вы организуете целочисленные вычисления на FPU (это не дикость: Turbo Pascal имел ажно специальный тип Comp для этих целей), а потом начинаете работать с данными из CPU, то вам нужно использовать либо LOCK, либо WAIT, иначе атомарности может и не получиться.
Я ни с чем оне спорю, я просто объясняю свою позицию, что неоднозначности с синхронизацией в работе процессора не существенны для обучения на императивных языках, где действительно время и порядок выполнения операций прогнозируемы.
На однопроцессорной системе, в случае когда не используется сопроцессор и так далее? Да, наверное. Но как-то в ваших предыдущих выступлениях я этого не уловил. Наоборот — там были странные рассуждения про «атомарные арифметические операции» и прочее. Которые нифига не атомарны (если не прилагать специальных усилий) даже при использовании DOS'а. Уже в IBM PC они не были атомарными — и на это легко можно было нарваться если прерывания перехватывать (да, да, в те времена это было нормальным и естественным), 8087й процессор или DMA использовать.
Между «вы, скорее всего, на это не наткнётесь в своих учебных программах» и «процессор не переключит контекст, пока он выполняет по сути атомарную операцию сложения» — дистанция огромного размера.
Современные компьютеры выполняют миллиарды операций в секунду (а скоро могут и до триллионов добраться) — при таких масштабах оказывается, что вещи, случающиеся «очень редко», происходят, скажем, раз в минуту. Вам будет приятно пользоваться программой, которая раз в минуту падает? Вот об этом и речь.DistortNeo
15.07.2016 20:51Касаемо 8086: да, прерывание может произойти во время выполнения команды: процессор может считать из памяти операнд и начать выполнять операцию, но не успеть записать результат. С точки зрения программиста это будет выглядеть как если бы команда не выполнялась вообще.
DMA и сопроцессор — отдельные темы. Скорее всего, вам никогда не понадобится лезть в область памяти в тот момент, когда с ней работает сопроцессор или гадит DMA.khim
15.07.2016 21:43Скорее всего, вам никогда не понадобится лезть в область памяти в тот момент, когда с ней работает сопроцессор или гадит DMA.
Про DMA — не знаю, наверное. А с сопроцессором как раз это постоянная история. Вычислили вы что-нибудь этакое (размер какого-нибудь буфера) с использованием плавучки (типичный пример: «время ожидания» и «частота опроса» заданные как числа с плавающей точкой), а потом — крутитесь в цикле обработки. Забудете WAIT — получите джиттер в лучшем случае (это если вы потеряете только один «цикл обработки», если получите просто «мусор» в этой памяти, то программа просто упадёт, скорее всего).
Тут, правда, вам ещё и прерывания будут подмешаны в кучу… но, в общем, на PC («настоящей PC», модель 5150) это бола та ещё головная боль.
Интеграция сопроцессора в 80486й (и все последующие модели) — одна из вещей, где количество абстракций упало со временем, а не возросло… правда тот же 80486й добавил кеш, так что в целом — «протечек» стало больше… но конкретно «пляски с бубном вокруг сопроцессора» 80486й (и 68040 у «конкурентов» — что интересно тоже одновременно добавивший кеш и сопроцессор на кристал) — оставили в прошлом.DistortNeo
15.07.2016 23:33Обычно заботу о вызове WAIT берёт на себя компилятор.
Пикантная ситуация возможна, опять же, при прерываниях, если обработчик прерывания хочет прочитать область памяти, куда может писать сопроцессор. Обработчик прерываний не имеет права вызвать WAIT.khim
16.07.2016 02:16Обычно заботу о вызове WAIT берёт на себя компилятор.
Если не используется каламбур типизации.
Обработчик прерываний не имеет права вызвать WAIT.
Кто ему вдруг запретит? Я боюсь вы путаете запрет, который налагают многие операционки, (для упрощения написания x87 эмуляторов) с ограничениями железа.
Впрочем всё это ушло уже ооочень далеко от вопроса о том, как изучать языки программирования.
DrPass
16.07.2016 19:46> На однопроцессорной системе, в случае когда не используется сопроцессор и так далее?
На любой. Если вы сами ничего специально для этого не сделаете, вы не получите непрогнозируемый результат. Ни на 8086, ни даже сейчас, т.к. ОС контексты процессов тоже не переключает произвольным образом, а делает это по планировщику.
> Вам будет приятно пользоваться программой, которая раз в минуту падает?
Я, честно говоря, не понял смысла этого замечания. Я вроде бы нигде не писал, что «долой ГМО и синхронизацию потоков в многопоточном приложении». Если был нетрезв и написал, дайте цитату.
VolCh
14.07.2016 19:33Даже если процессор отдаёт память DMA явно, чисто в теории далеко не факт, что он не делает несколько захватов-отдач во время одной команды. Грубо: захватили память, прочитали команду, отдали память, дешифровали команду, поняли что операнд в памяти, захватили память, прочитали операнд, отдали память, выполнили операцию, поняли, что операнд тоже нужно поместить в память, захватили, записали, отдали. Итого минимум одно окно, где может вмешаться тот же DMA.
DrPass
16.07.2016 20:29> Итого минимум одно окно, где может вмешаться тот же DMA.
DMA не обладает такой самостоятельностью. Он вмешивается только тогда, когда процессор запустит обмен через DMA. После чего он держит шину до тех пор, пока не окончится его цикл.
khim
12.07.2016 16:59Если развить вашу мысль, разве не получится, что магия вообще везде, и иногда работает так, а иногда — иначе?
Конечно получится. Но не стоит забывать о том, что появилась она — совсем недавно.
Ну разве что в ОС жёсткого реального времени или на голом железе (очень распространённые среды для обучения начинающих программистов, ага).
Почему нет? В MS DOS магии было вполне немного. Потому, в частности, за MS DOS держались очень долго. Windows, да — это уже проблема, конечно…
А вот от такой, к примеру, магии и вообще ничего не спасёт: http://stackoverflow.com/questions/11227809/why-is-it-faster-to-process-a-sorted-array-than-an-unsorted-array
Опять-таки: любая система на базе 80386 «без наворотов» (читай: без кеша).
В целом — вы правы: чем дальше в лес — тем сложнее от магии избавиться. Но это не значит, что это — что-то хорошее. Для обучения — это плохо.
P.S. Принцип примерно тот же, что и на уроках труда. Станки, на которых детей обучают программрованию — это что-то ближе к XIX веку, чем к XXI. И не потому что они дешевле, чем современная супер-пупер наворочанная железка. А потому что его элементарно проще понять и освоить. И не надо говорить, что сегодня от этого никуда не деться: купите Arduino — и всё: нет больше никакой магии. Причём оно же ещё и стоит копейки…
FatumFL
07.07.2016 19:50Чего тогда не BASIC? Тоже очень популярный язык у школьных преподавателей. И простой. Но я бы предпочел Python. Легок в освоении, и можно одним языком покрыть практически все основы: от циклов и ветвлений до лямб, рекурсий и ООП.
ru_vlad
07.07.2016 20:00В начале пед карьеры Бейсик тоже тоже был ;)
Но, сейчас он исключен из олимпиадного набора языков, а в олимпиадах мы участвуем :) И опять же в Бейсике трудно понять программный блок.
Против Питона я не против (он мне нравится), но ко мне приходят школьники разного уровня, одни все схватывают на лету (таких единицы) другие со«скрипом» циклы осваивают. Были классы в которых успевал не только ООП показать но Ассемблер чуток познакомить, сейчас это только в памяти.MacIn
08.07.2016 15:39И опять же в Бейсике трудно понять программный блок.
Эммм… просто: нет. Блоки как блоки. Модули, функции, составные операторы (по сути, не синтаксически).
DistortNeo
07.07.2016 21:05+1BASIC изучали не от хорошей жизни: просто это было единственное, что можно было использовать на допотопных компьютерах.
VolCh
08.07.2016 08:27Навскидку, что использовал в конце 80-х — самом начале 90-х на допотопных компьютерах минимум 4-х разновидностей (клоны Радио-86РК, Спектрума, БК-0010, Yamaha MSX2)
— фокал
— бейсик
— си
— паскаль
— форт
— дбэйс
ну и ассемблеры
MacIn
08.07.2016 15:40+1Даже на любительском Радио-86РК с 32Кб памяти был спектр языков.
Бейсик понятен. Всем. Поэтому и используется(овался).
Error1024
08.07.2016 13:28+1Поддерживаю, начинать надо с Паскаля, от #define, заголовочных файлов, неясного printf у людей которые едва начали сносит мозг.
И при этом в отличии от Ada, Modula, Oberon… Паскаль жив и применяться в коммерческой разработке, что увеличивает полезность занятий.DistortNeo
08.07.2016 13:40Модель с инклюдами, разделением на заголовочные и исполняемые файлы — это рудимент, тянущийся со времён C. Беда в том, что модули для C++ так и не ввели.
potan
07.07.2016 12:54+8Для понимания C++ стоило прочитать «Дизайн и эволюция языка C++» Страуструппа. Он там не столько описывает язык, сколько объясняет мотивацию принятия тех или иных решений. После этого многое становится значительно понятнее. Не знаю, есть ли аналогичная по современной редакции языка.
Сам я начинал с МК-52, ассемблеров и паскаля, но серьезно увлекся после изучения C. В конце концов перешел на функциональщину, но путь был довольно длинный.
Я считаю, что в качестве первого языка надо выбирать язык, позволяющий создавать абстракции. Программирование заключается именно в этом — в создании и повторном использовании абстракций. Но C в этом отношении очень плох.
И не надо бояться, что человек не поймет принципов работы компьютера. В том же старом добром SICP разбирают не только устройство памяти, но даже разрабатывают достаточно реалистичную модель процессора. Это лучший учебник, не смотря на то, что сам язык Scheme уже несколько устарел.
fly_style
07.07.2016 15:15+1В принципе согласен с автором, но от себя хочу заметить: я бы рекомендовал после С изучить функциональный язык типа того же Lisp(Sheme) или Haskell. Просто, исходя из личного опыта, пересаживаться с императивщины на функциональщину очень тяжело по причине сложности понимания парадигмы, так что уже лучше «поломать» мозг в начале своего пути разработчика, чем уже не будучи новичком, часами сношать свой мозг, пытаясь уловить принципы функционального программирования.
compilator
07.07.2016 19:50Вы в тридцать лет пошли в школу? Это очепятка? :)
arielf
07.07.2016 19:51тринадцать
compilator
08.07.2016 07:25Извините, хотел удалить комментарий, но было уже слишком поздно )
Надо больше отдыхать видимо.
Tercel
07.07.2016 19:51+6Большинство американских университетов начинают с Питона. Он и читабелен и популярен и легко изучается.
Pilat
07.07.2016 20:01Лучше параллельно изучать С и Ассемблер. Это даст представление о том, что лежит за компилируемыми языками. А потом что-то скриптовое, чтобы почувствовать себя человеком и, при этом, понимать чем расплачиваются скриптовые языки за удобство.
webkumo
07.07.2016 21:39+1Компилируемые языки говорите?.. А я вот так и не подружился в своё время ни с tasm, ни с masm… А лабы делать надо — горят… плюнул и в hiew com файл написал (благо com-файлам линковки и заголовки exe-шные не нужны… можно сразу исполняемый код фигачить).
glorfindeil
07.07.2016 20:30+1Эх, помню как в универе С++ заставил меня возненавидеть программирование, а потом другой язык вернул интерес, и принес понимание, что можно заниматься задачами не закапываясь в ненужные технические детали.
danielnewman
07.07.2016 21:49«Знание принципов проектирования программ, алгоритмов». Вот про это все тело ноет. Где оно написано? Утомился от собственного изобретения велосипедов там, где уже давно на ракете летают.
arielf
07.07.2016 22:07+2В книгах на английском языке. Например, Code Complete by Steve McConnell по кодированию. И список рекомендаций к ней.
voddan
07.07.2016 22:03+2Невероятно, но Java вообще изучать не предлагается. Java является промышленным языком #1 последние 10 лет по количеству работы, проектов, и инфраструктуры. Кроме того, Java весьма интересна как язык своим дизайном, например Python и другие языки открыто заимствовали идеи библиотек и фраймворков. С академической точки зрения, JVM это предмет для обязательного изучения любого программиста-теоретика и/или перформансника. Одна JMM чего стоит!
arielf
07.07.2016 22:16Java рарабатывалась как костыль для неосиливших C++. Она — Smalltalk для нищих, с урезанным… практически всем. Когда Sun внезапно предложила язык с привычным синтаксисом, многие компании, включая IBM спешно переделали свои SVM в JVM. Привычный синтаксис же важнее.
vlad72
08.07.2016 00:29Так Вы имеете в виду «изучение как хобби»? А то можно срачь развести про недостатки С++.
glorfindeil
08.07.2016 00:35+1Это так, но в прошлом. В настоящем времени Java — это мощная платформа, явно сильнее чем то, что предлагает Smalltalk и не слабее того, что есть в мире C++
webkumo
08.07.2016 01:40Вы бы на холивор-то не нарывались бы ;)
Если вы не знаете какой-то язык и его экосистему (а Java не просто так хватанула такой кус разработки) — то это не повод пытаться принизить этот язык и возвысить какой-либо другой.
DrPass
08.07.2016 00:41+5С академической точки зрения Java в общем-то не интересна. Синтаксис языка крайне жесткий и для «гимнастики ума» не подходит. Научиться писать код _качественно_ Java тоже не особо стимулирует. Разобраться с анатомией работы компьютера тоже не получится, ибо JVM. ИМХО, Java — это одна из тех платформ, которые надо учить тогда, когда ты сознательно решил работать в этой области. Тогда, когда уже достаточно потратить на изучение самого языка день-два, а остальное время — на те библиотеки и фрейморки, которые нужны для работы.
voddan
08.07.2016 09:20-2Если под «гимнастикой ума» понимать то что предлагает например Ruby, то Java конечно не в той категории. Несмотря на ограничения синтаксиса, гибкость Java не подлежит сомнению именно из-за количества паттернов и фраймворков которые ее поддерживают. С академической точки зрения Java (JVM) интересна как первый язык решивший проблему линковки библиотек. Вся та мощь и гибкость которую предоставляют полноценная рефлексия, пост-обработка бутекода, аннотации и класслоадеры никогда не снилась C++ и подобным.
DrPass
08.07.2016 09:57+2> интересна как первый язык решивший проблему линковки библиотек
Вот не соглашусь. Это важно как раз с _практической_ точки зрения. А платформа для обучения программированию как раз должна иметь минимум автоматики, или хотя бы режим работы без автоматики. Тот же С++ (хотя «на старте» к нему действительно лучше не прикасаться по моему мнению), имеет отличную фичу, в нём вы можете сначала мучиться с ручным управлением жизни объектов, а потом изучить смартпойнтеры, и главное — легко понять, как они устроены. А в Java, если вы новичок в программировании, вы это воспримете как должное, и не будете понимать, что находится «под капотом» у этого механизма. И если с С, Паскаля и С++ вы можете легко перейти на управляемый код, то наоборот это будет весьма болезненно.voddan
08.07.2016 10:21-1Вы хотите сказать что в статье предлагается изучить 8 (!!) языков и все это на стадии «новичок»?
Повторяюсь, я говорил про линковку библиотек, а не управление памятью. Как много людей по Вашему знают что происходит при динамическом подключении .o? Или еще лучше .dll на Windows? Ответ — единицы, остальные «воспринимаю это как данность» (и отлично живут и работают).
Или то-же управление памятью. Кто из C/C++ программистов представляют себе как аллоцируется память? Еще лучше, как она деаллоцируется? А ведь это одна из самых важных характеристик, влияющих на быстродействие программы. Опять же — единицы.
Ну или венец творения — что происходит при ошибках и крашах? В частности при обращении по NULL? Что, «система гарантирует корректность»? Нет, не везде и не всегда. Разные ОС делают это по-разному. И все это необходимо досконально знать чтобы написать минимально-надежную программу.
Простите за прямоту, но мне кажется Вы оперируете какими-то стереотипами что C/C++ сложнее или проще чем Java. В C полно магии на уровне операционки и/или процессора которые нужно хорошо понимать чтобы написать просто корректную программу, я уж не говорю быструю. И наоборот, хорошие Java программисты великолепно разбираются в процессорах, операционках, компиляторах и много в чем другом, что позволяет им выжимать максимум из JVM (те самые случаи когда Java программа быстрее C++ аналога 0_о )DrPass
08.07.2016 10:55+3> Как много людей по Вашему знают что происходит при динамическом подключении
Полагаю, большинство программистов, которые пришли в профессию с интересом, а не потому что высокие зарплаты, это знают.
> Кто из C/C++ программистов представляют себе как аллоцируется память?
Из С/С++ программистов также подавляющее большинство. Это один из тех моментов, ради которых их приглашают на работу :) Вот Java-программисты в массе своей не знают, собственно, им оно обычно и не требуется.
> Ну или венец творения — что происходит при ошибках и крашах?
Ничего особенного в фреймах исключений нет. И кстати, С++ программист обычно знает как работает механизм исключений на низком уровне, а для Java-программиста это просто экземпляр класса с информацией об ошибке.
> В C полно магии на уровне операционки и/или процессора
> которые нужно хорошо понимать чтобы написать просто корректную программу
Ну не перегибайте. В С/С++ можно ничего не понимать о работе операционки и процессора, и писать точно такие же программы, как пишут ничего не понимающие программисты на других языках. Единственное, в С надо запомнить одну жизненно важную парадигму — выделил память, не забудь её освободить. Всё остальное уже плюшки.
> мне кажется Вы оперируете какими-то стереотипами что C/C++ сложнее или проще чем Java
Не надо объединять С и С++, это совершенно разные вещи. И да, C++ сложнее чем Java. Значительно сложнее. Это не стереотип. Мне пришлось и Java-программистом не один год поработать, и на С++. Количество абстракций, которыми оперирует программист С++, больше на порядок. Причем я не говорю, что это хорошо, я абсолютно исренне считаю, что это излишняя сложность.
> хорошие Java программисты великолепно разбираются
Хорошие программисты великолепно разбираются во всём. Проблема в том, что они в меньшинстве.
arielf
08.07.2016 18:48Ну зачем? В ней предлагаю учить лишь первые 3 по очереди, а после уже выбирать по вкусу. Или, по крайней мере, ознакомиться.
arielf
08.07.2016 18:46Если Вы от Java в таком восторге, что же будет при знакомстве со Smalltalk, скажем VisualWorks или GemStone?
voddan
08.07.2016 18:53+1Ничего не будет. Я уже знаком со Smalltalk.
Вы рассматриваете языки сами по себе, без всего что их окружает. Такой подход совершенно не описывает реальную полезность технологий. Java как язык могла бы спокойно компилироваться в машинный код и это действительно был бы урезанный C++. Я (и некоторые другие) в восторге не от языка, а от JVM-the-platform, и мои комментарии в основном относятся к платформе, а к языку.
snuk182
08.07.2016 13:25> Научиться писать код _качественно_ Java тоже не особо стимулирует.
Есть минимум две вещи, которым джава способствует.
1. Объектность. Именно потому, что в джаве все есть объект, и под эти объекты практически нет синтаксического сахара, многие принципы ООП более очевидны. Да, тут все манипулируется указателями (кроме примитивов), ни слова ни про стек, ни про кучу, зато можно отлично набить скиллы моделирования иерархий объектов и их взаимодействия.
2. Все же джавой пользуются, как выше верно заметили, в контексте фреймворков, а не голого языка. Фреймворки же — устоявшийся стандарт с собственными жесткими правилами разработки, куда жестче, чем у языка в общем. Что попало куда попало здесь воткнуть уже серьезно сложней.
DmitryMelnyk
08.07.2016 00:45Как начинать изучать языки программирования в школе?
Что касается меня то я не знаю с какого языка начинать но мне кажется, что главным здесь должен быть не язык, а преподаватель который сможет зажечь огонь интереса в глазах ребёнка. А уже на топливе этой страсти и увлечения любой язык пойдёт как по маслу. И наоборот: даже самый «подходящий» язык не переварится если его преподаёт скучный учитель.
Если есть желание можно дать ученикам паяльник в руки и вместе с ними спаять несколько вентилей из транзисторов для демонстрации булевой алгебры. Загоревшимся глазам гораздо интереснее рассказывать о битах и байтах, механике работы процессора, памяти — и им будет чего рассказать на свидании девушке:)
Если создание реального рабочего проекта вызывает восторг у людей — то почему бы и нет. Автор верно упомянул о том как люди ловятся на гуишных приложениях. Обсасывание черствых структур данных — скучное занятие, особенно когда на начальных этапах развития не можешь уловить зачем, для чего, когда эти знания пригодятся и нужно ли тебе вообще это знать в свои -надцать лет. Ведь так хочется «потыкать» кнопочки: они гораздо реальнее и дают мнимую возможность поставить себя рядом с создателями программ с которыми ты работаешь каждый день (помню свои возвышенные чувства и школьную гордость от написания примитивного аудиоплеера на C++Builder:))). Но если работа с абстрактными структурами данных для тебя превращается в захватывающий квест, полон интересных приключений — то я только за.
Мой подход таков — нужно начинать с того, что у тебя зажгёт огонь в глазах и вызовет восторг в душе. А тогда уже в это разгоревшееся пламя понемножку подбрасывать сырые но «правильные» дрова.
Всем побольше интересных увлекательных книг!vlad72
08.07.2016 05:33Так откуда Вы можете знать, что зажгет в Вас огонь, не попробовав? Поэтому начинать надо с Паскаля, потом Си, а потом уже по профессии.
DmitryMelnyk
08.07.2016 20:45Нужно пробовать)
Я лично пробовал с gwbasic, а потом pascal но не берусь утверждать, что с их нужно начинать потому, что я не проходил иные пути. Мне вот стало интересно если бы я начал двигаться с функциональных языков и алгебраических типов данных.
vlad72
08.07.2016 23:36Правильное обучение это путь от простого к сложному, а не наоборот…
khim
09.07.2016 00:47-1Только вот вопрос простоты — он относительный.
Возьмите какой-нибудь «язык RL». Вот описание:
Символ — любая последоваьтельность составленная из букв латинского алфавита. При этом большие и маленькие символы мы считаем одинаковыми.
Примеры:
A, B, symbol, AnotherSymbol — символы
НеСимвол, a2, abc-d — не символы
Терм — любой символ, а также любое выражение, заключённое в скобки. При этом выражение — любая последовательность термов (в том числе и пустая), разделённая пробелами.
Примеры:
A B CCC D — выражение из четырёх термов
(A B) — терм, состоящий из одного выражения, которое, в свою очередь, состоит из выражения, состоящего из двух символов в скобках
(()) B CCC — выражение из трёх термов, первый из которых состоит из единственного терма в скобках
Программа на языке RL представляет собой выражение, состоящее из термов специального вида, называемых функциями.
Функция — это выражение следующего вида:
(F (T1… Tn) B)
где
F — символ, называемый именем функции
T1… Tn — символы, называемые аргументами функции
B — терм, называемый телом функции (обязан имать один из представленных ниже видов)
Имена функций, описанных в программе не должны совпадать. Для каждой функции и для каждого набора значений определён результат, вычисляемый по описанным ниже правилам. Результатом работы программы является результат вызова первой функции на аргументах, заданных при запуске программы.
Термы, допустимые в качестве тела функции и их значения:
(abort) — этот терм не имеет параметров и его значением явлется символ undefined
(quote x) — этот терм не имеет параметров и его значением является выражение x
Пусть T1… Tn — термы, Z1… Zn — соответствующие им значения
(first T1) — значением этого терма является первый терм выражения Z1 (если Z1 пусто, то значением является символ undefined)
(bf T1) — значением этого терма является выражение, полученное отбрасыванием первого терма выражения Z1 (если Z1 пусто, то значением является символ undefined)
(expr T1… Tn) — значением этого терма является выражение Z1… Zn
(equal T1 T2) — значением этого терма является символ true если Z1 и Z2 совпадают и символ false, если они различны
(symbol T1) — значением этого терма является символ true если Z1 состоит из одного символа и false — во всех остальных случаях
(if T1 T2 T3) — значением этого терма является символ Z2, если Z1 — это символ true и Z3 — во всех остальных случаях
(br T1) — значением этого терма является Z1 в скобках
(cont T1) — значнием этого терма является выражение X, если Z1 это терм, состоящий из выражения X в скобках, в противном случае значением является символ undefined
(call F T1… Tn) — значением этого терма является значение тела функции F на аргументах Z1… Zn при условии что функция с именем F существует в программе и имеетnаргументов, в противном случае значение этого терма — символ undefined
Это — полное и исчерпывающее описание вполне себе функционального языка программирования. На котором можно писать сортировки и оценивать их сложность, расставлять ферзей и делать многое другое.
Сравните с описанием какого-нибудь С или даже Pascal'я… У нас нет ни указателей, ни «адресной арифметики», ни аллокации памяти — нет вообще ничего кроме символов, термов, выражений и их значений. Куда проще-то?vlad72
09.07.2016 13:17Так простота в ОБУЧЕНИИ определяется не только количеством ключевых слов, но и понятности их применения для человека, НЕЗНАКОМОГО с программированием. Поэтому сначала императивные ЯП, потом ОО-ЯП, потом Ф-ЯП — именно в таком порядке. Ну или Вы тогда кардинально несогласны со статьей Пола Грэма «Побеждая посредственность», а я с ней согласен ))
khim
09.07.2016 13:37Так простота в ОБУЧЕНИИ определяется не только количеством ключевых слов, но и понятности их применения для человека, НЕЗНАКОМОГО с программированием.
В этом случае Pascal — оказывается ещё хуже RL'я.
В случае с Pascal'ем у вас появляется куча понятий (память, массивы, изменяемые состояния и прочее, прочее, прочее). Тут же — простейшие понятия, пожалуй даже проще синусов-косинусов. Если вы можете понять что такое квадратный корень или экспонента, то почему для вос возникают сложности с пониманием того, что такое терм?
Ну да, у нас тут аж целая дюжина функций — ну так их не обязательно сразу все вводить. Введя только лишьfirstиbfвы уже можете рассказывать про то, как сделатьsecond, а как только у вас появилисьifиequal— вы можете рассказать как реализовать логические операции. С появлениемcall— можно уже сделать и арифметику и сортировки (да, собственно, язык становится полным по Тьюрингу), так что больше ничего от языка и не требуется для изучения теории (на практике, конечно, хочется чтобы в языке хотя бы числа были, а в идеале — так даже и строки). А для практики — реализуйте разные варианты вычисления «чисел Фибоначчи» — и уже можно говорить о сложности (экспоненциальная сложность от линейной отличается настолько заметно, что никакие гагагерцы не спасут), кешировании и прочем.
Да, в изучении RL'я сразу возникают кучи разных моментов — но это же и хорошо! Тут вот уже обсуждали разницу между «accidental complexity» и «essential complexity». Так вот в RL'е вы с места в карьер сталкиватесь с «essential complexity» (с той самой с которой вам потом придётся бороться столько времени сколько вы будете заниматься программированием) — и научаетесь с ней бороться.vlad72
09.07.2016 13:51> В случае с Pascal'ем у вас появляется куча понятий…
Да, но все они интуитивно понятны начинающему программисту! Достаточно просто владеть немного математикой.
> Да, в изучении RL'я сразу возникают кучи разных моментов — но это же и хорошо!
Нет, это плохо! Так как это чисто программистские штучки и непонятно ЗАЧЕМ они возникают, с ЧЕМ они борются. То есть Вы предлагаете решения, не обозначив проблемы. Это с точки зрения бритвы Оккама плохо. А если идти путем ИП->ООП->ФП всё очень четко и понятно с точки зрения ОБУЧЕНИЯ, так мы в самой жизни обычно мыслим императивно.
Вы рассматриваете простоту ПРИМЕНЕНИЯ, а речь про ОБУЧЕНИЕ. И это не одно и тоже. Боюсь, что Ваш метод готовит как раз «кодеров» ))khim
09.07.2016 16:31Да, но все они интуитивно понятны начинающему программисту!
Ой ли? Я видел кучу людей, которые при описании того, что такое «список» (классический, с указателями на элемент до и после) впадали «в ступор» и им требовалось рисовать разные картинки на бумажке, чуть ли не тащить за руку в библиотеку и показывать как там картотека устроена!
Это вам так кажется, что «они все интуитивно понятны», а с RL'ем — у вас есть какие-то проблемы… Потому что понятия Pascal'я вы освоили когда-то давно и уже думаете в этих терминах, а для новичка — вовсе не факт, что Pascal понятнее RL'я.
Контрольный вопрос: вы вообще с Logo когда-нибудь сталкивались? А это, как бы, язык специально созданный для обучения програмированию.
Поиграйтесь с ним, а потом скажите к чему он ближе — к RL'ю или к Pascal'ю…
Так как это чисто программистские штучки и непонятно ЗАЧЕМ они возникают, с ЧЕМ они борются.
Они возникают просто потому что у нас такие «правила игры». Вы же не спрашиваете почему конь в шахматах прыгает «буквой Г», а слон ходит «по диагонали»? Вот и тут та же история.
Собственно это вообще главный шаг, через который должен переступить будущий программист: он должен понять, что в компьютере нет ни зверушек, которые мы видим на экране, ни даже текста, который мы редактируем. Всё что представляет из себя компьютер — это нолики и единички (много ноликов и единичек) и некоторые очень странные, но фиксированные (хотя и сложные) правила игры. Игра в бисер этакая. И спрашивать «зачем» во многих случаях бессмысленно — просто потому что нет на этот вопрос ответа. Хотя всегда есть ответ на вопрос «почему» — но во многих случаях ответ на него «ну… потому что так вышло» или, гораздо чаще, «потому что это было нужно для решения задачи, которая сейчас уже не актуальна».
А если идти путем ИП->ООП->ФП всё очень четко и понятно с точки зрения ОБУЧЕНИЯ, так мы в самой жизни обычно мыслим императивно.
Если бы мы мыслили императивно, то мы никогда в жизни ложку ко рту бы не поднесли! Тактовая частота «процессора» головного мозга — порядка тысячи герц, время реакции, которое нужно, чтобы не пролить суп — меньше секунды. Так что мыслим мы, вы уж извините, никак не последовательно и не императивно. Мыслим мы как раз функционально. Вот говорим мы императивно, пишем тоже — потому что у нас одна глотка и пара рук.
Вы рассматриваете простоту ПРИМЕНЕНИЯ, а речь про ОБУЧЕНИЕ.
Вот как раз применять RL я бы на практике не советовал. Так как в нём нет даже чисел то считать что-нибудь на нём, мянко говоря, небыстро. Это — как раз учебный язык, которые идёт не со стороны того, что в компьютере есть, а со стороны того, что нам от него нужно.
Боюсь, что Ваш метод готовит как раз «кодеров» ))
Практика — вещь упрямая. Люди, решившие на RL'е какую-нибудь достаточно сложную задачу, как правило, потом достаточно легко осваивают и Pascal и C++ и любые другие языки. Люди, которые объясняют, что RL — это фигня и учить нужно Visual Basic, которым они уже сейчас отлично владеют — редко когда становятся программистами (хотя часто добиваются успеха в других, смежных, областях).MacIn
09.07.2016 16:50Ой ли? Я видел кучу людей, которые при описании того, что такое «список»
Мне кажется, подразумевается императивный подход как таковой — он действительно ближе человеку, является прямым аналогом инструкции по выполнению каких-либо действий; вместо списков могут использоваться массивы (на ранней стадии, естественно). Само слово «список» дезориентирует новичка, потому что бытовое «список» аналогично массиву.
Мыслим мы как раз функционально. Вот говорим мы императивно, пишем тоже — потому что у нас одна глотка и пара рук.
Хорошо. Примем на секунду вашу точку зрения; что это меняет? Процессор — императивен, выполняет команды одну за одной. Функциональные языки, как и логические — это абстракция. Протекающая иногда (отсечение в Прологе, например).
Сама жизнь императивна: время течет в одну сторону. Мы не можем сначала пройти в дверь, а потом открыть ее.
Это — как раз учебный язык, которые идёт не со стороны того, что в компьютере есть, а со стороны того, что нам от него нужно.
В таком случае, мы получаем тех же самых людей, которые не понимают ограничений машины. Вот есть у нас функция, вот еще одна, их результат вычисляется условно-мгновенно. Будто бы. А на деле — нет, машина императивна.
как правило, потом достаточно легко осваивают и Pascal и C++ и любые другие языки.
Потому что они ближе и машине, и человеку. Здесь ошибка выжившего: человек, который освоил более абстрактную штуковину, скажем так, «лучше мыслит», поэтому ему легко дадутся императивные языки. Тот, кто мыслит «похуже» (слабо тренирован в обучении), все равно освоит императивную парадигму, а вот на функциональную «мозгов не хватит». Получается иллюзия того, что в первом случае функциональный подход «открыл чакры».khim
09.07.2016 17:57Сама жизнь императивна: время течет в одну сторону.
Это у Ньютона время в одну сторону течёт. А вот теория относительности — вносит поправки: там уже далеко не для всех событий можно сказать — что произошло раньше, что позже.
Мы не можем сначала пройти в дверь, а потом открыть ее.
Это если мы в гордом одиночестве, да. А вот если у нас открывает дверь Вася, а заходит туда Маша — то она запросто может и «огрести» если Вася зазевается.
Процессор — императивен, выполняет команды одну за одной.
Это так в 60е годы было. А сейчас у вас уже в кармане — телефон, где процессор ни разу не исполняет «команды одну за другой» и где «Вася» и «Маша» должны прилагать специальные усилия для того, чтобы в дверях не столкнуться.
Вот есть у нас функция, вот еще одна, их результат вычисляется условно-мгновенно. Будто бы.
Пока вы выполняете программы для RL'я на бумажке — да. Но стоит вам запустить реальный интерпретатор — и у вас возникнет совсем другое ощущение. И можно будет поговорить о сложности, затратах памяти и многом другом.
Здесь ошибка выжившего: человек, который освоил более абстрактную штуковину, скажем так, «лучше мыслит», поэтому ему легко дадутся императивные языки.
Ошибка выжившего — это как раз у нас сейчас в индустрии. Последние лет 20 разработчики железа вбухивают колоссальные средства в то, чтобы поддерживать иллюзию «императивного железа». На это уходит от 90% и больше «транзисторного бюджета» — и сопоставимое количество энергии. Причём чем дальше в лес — тем сложнее это делать.
Вопрос отказа от императивной парадигмы сегодня — это вопрос времени и денег: пока всё ещё оказывается дешевле эмулировать императивную парадигму (в основном потому что вокруг нас из-за «ошибки выжившего» куча императивного кода), но, как уже было сказано, чем дальше — тем дороже это обходится.
Зачем же учить людей тому, от чего им, рано или поздно, придётся отказываться?MacIn
09.07.2016 18:23Это у Ньютона время в одну сторону течёт. А вот теория относительности — вносит поправки: там уже далеко не для всех событий можно сказать — что произошло раньше, что позже.
Мы, на секундочку, об обучении программированию и тому, какие концепции легче понимаются за счет присутствия в жизни среднего человека.
Это если мы в гордом одиночестве, да. А вот если у нас открывает дверь Вася, а заходит туда Маша — то она запросто может и «огрести» если Вася зазевается.
Не имеет значения. Это просто два последовательных процесса, выполняемых двумя «ядрами». То, что они действуют параллельно, не отменяет того, что каждый последователен в действиях.
Это так в 60е годы было. А сейчас у вас уже в кармане — телефон, где процессор ни разу не исполняет «команды одну за другой» и где «Вася» и «Маша» должны прилагать специальные усилия для того, чтобы в дверях не столкнуться.
Исполняет так же. Реордеринг, переключение задач — частности. Суть та же — сначала одна команда, затем другая. Деже если это одна команда задачи А, потом одна команда задачи Б. В некоторый промежуток времени, квант, задача последовательна. Переключение — абстракция, каждое ядро исполняет команды императивно.
Как ни крути, объяснить императивный подход на примере двери с 1м человеком, а потом — борьбу двух императивных процессов за разделяемый ресурс на пример двоих проще раз так в 500, чем фнукциональную парадигму. И математика тут не поможет: человек решает задачу(пример, уравнение) последовательно, действиями (это, кстати, контр-пример к вашему «мы мыслим функционально»).
Но стоит вам запустить реальный интерпретатор — и у вас возникнет совсем другое ощущение.
Ощущение, именно ощущение. Запуская Пролог-машину, у меня тоже есть ощущение, что машина выполнила весь вывод, все резолюции за раз. А на деле все тот же императив под капотом. Вот если я спаяю комбинационную схему… то тогда… и то придется иметь дело со скоростью распространения сигнала.
Последние лет 20 разработчики железа вбухивают колоссальные средства в то, чтобы поддерживать иллюзию «императивного железа».
Не императивного железа, а машины. Да, сигнал распространяется параллельно, но мы с ним не работаем. Машина, самый глубокий уровень, который трогают руками — это машинный код (в крайнем случае, микрокод), и здесь все последовательно. У нас есть синхросигнал — аналог того самого времени, которое течет в одну сторону, который обспечивает выполнение шаг за шагом.
Зачем же учить людей тому, от чего им, рано или поздно, придётся отказываться?
Затем что в обозримом (субъективное словечко, алярм) будущем не предвидится массового отказа.
Получается, что ф.п. — это абстракция над императивной машиной, которая является абстракцией над неимперативным железом.
Это пока что еще один уровень абстракции.
khim
09.07.2016 19:33Мы, на секундочку, об обучении программированию и тому, какие концепции легче понимаются за счет присутствия в жизни среднего человека.
Ни концепций, связанным с функциональным программированием, ни концепций, используемым императивным в жизни обычного человека нет.
Это просто кажется, что какой-нибудь «сборник рецептов» — это «почти программа». Выглядит похоже, но строчка, которая встречается почти в каждом рецепте — перечёркивает всё напрочь. Магическая строчка, выгрядит весьма невинно:соль, перец — по вкусу
Но дело в том, что она неявно вносит в рецепт «здравый смысл», «опыт» и прочие вещи, которых компьютер начисто лишён. И, собственно, будущих «программистов» и «непрограммистов» разделяет именно «принятие» этого факта. Не понимание, а «принятие». Человек может умом понимать, что компьютер — это железяка, гора транзисторов — и больше ничего, но пока он на подсознательном уровне ожидает, что компьютер будет «действовать разумно» — программистом он не станет.
Что самое смешное, так это то, что все эти бесконечные слои абстракций — это попытка сделать-таки компьютер… ну пусть не разумным, но хотя бы не таким патологическим кретином! И обычных людей в обычной жизни часто удаётся обвести вокруг пальца… но задача программиста, собственно, во-многом в том и заключается, чтобы разобраться в тех случаях, когда абстракция «протекает» и иллюзия «разумности» улетучивается!
Потому убедить ученика в этом становится всё сложнее — но это критически важный момент. Вам долго и упорно приходится вдалбливать тот факт, что «машины — это куча транзисторов» в головы ученков.
Либо, как альтернатива — стартовать из точки, где нет ничего лишнего (математические функции и их преобразование в машинные инструкции) и добавить потихоньку всё необходимое.
Практика показывает что результаты — отличаются разительно. Просто потому что наш мозг так устроен, что усвоить что-то ему гораздо проще, чем забыть.
В результате оказывается что при попытке пройтись по цепочке ИП->ООП->ФП слишком многие не доходят до конца.
Это пока что еще один уровень абстракции.
В каком-то смысле — да, в каком-то — нет. Сейчас вообще «всё смешалось в доме облонских». Вы про SSA что-нибудь знаете? Почитайте если будет время. Сейчас цепочка во всех современных системах выглядит так: императивный или функциональный язык язык->ФП-временное представление->императивный код->ФП-представление внутри процессора->ФП-железо. Иногда добавляется ещё пара слоёв :-)
В идеале от императивности нужно бы отказаться вообще, но для того, чтобы это реально сделать нужно чтобы цепочка начиналась с ФП-представления. С чем — пока что сложности, но потихоньку процесс идёт: во все современные языки потихоньку-полегоньку идеи ФП добавляются. Десятое правило Гринспена рулит…arielf
09.07.2016 20:57Ни концепций, связанным с функциональным программированием, ни концепций, используемым императивным в жизни обычного человека нет.
Ох неужели? В любой книге по алгоритмам сказано, что алгоритм — это последовательность действий. В 'Introduction to Algorithms' все примеры императивны. Любой химический или молекулярно-биологический протокол — императивен. Любая инструкция на производстве или в науке — императивна. Прошу прощения, но у Вас религиозный фанатизм.
khim
09.07.2016 21:34Прошу прощения, но у Вас религиозный фанатизм.
А у вас то, что называется клиповым мышлением.
Любая инструкция на производстве или в науке — императивна.
[Почти любая] инструкция предполагает оперированием понятиями, которые в эту инструкцию не входят. Именно поэтому историки, их читая, проводят годы, чтобы их расшифровать. И потому у китайцев «вдруг» прорыв происходит не когда им удаётся стащить описания техпроцесса, а когда к ним эмигрирует кто-нибудь, кто участвовал в его разработке.
Программирование же — это составление инструкций для абсолютного кретина, который не обладает.MacIn
09.07.2016 23:15[Почти любая] инструкция предполагает оперированием понятиями, которые в эту инструкцию не входят.
Это не делает ее неимперативной.
Программирование же — это составление инструкций для абсолютного кретина, который не обладает.
Хм… при этом императивного кретина в жизни представить может каждый, а вот функциоанльного — только под ЛСД.
MacIn
09.07.2016 23:09Ни концепций, связанным с функциональным программированием, ни концепций, используемым императивным в жизни обычного человека нет.
Большая часть жизни — императивна, см. пример с дверью. У любого человека. Упомянутый вами фактор субъективизма никакого отношения к обсуждению «императив вс функционал» не имеет. Возьмите не готовку, а кипячение воды в чайнике. Стирку. Совершение покупок. Все императивно, ничего фнукционального нет. Вообще.
Это просто кажется, что какой-нибудь «сборник рецептов» — это «почти программа». Выглядит похоже, но строчка, которая встречается почти в каждом рецепте — перечёркивает всё напрочь. Магическая строчка, выгрядит весьма невинно:
соль, перец — по вкусу
Не просто кажется, а так и есть. Эта строчка применяется императивно: строго после шага n, когда вкус блюда сформирован и его можно ощутить. Не функционально, а строго после шага n.
Потому убедить ученика в этом становится всё сложнее — но это критически важный момент.
На императивном подходе это сделать проще, чем с функциональным. Вот ты показал человеку, что если сначала сделать вывод на экран, а потом спозиционировать курсор, получится лажа, потому что компьютер — тупой исполнитель — и все ясно.
В результате оказывается что при попытке пройтись по цепочке ИП->ООП->ФП слишком многие не доходят до конца.
Разговор немного идет по кругу.
Это, возможно, вызвано тем, что некоторым людям в прицнипе тяжело осилить ФП, в отличие от ИП, которое встречается в жизни, см. пример с дверью. В силу неспособности понимать абстракции (коими является ФП) в принципе.
императивный код->ФП-представление внутри процессора->ФП-железо
Представление внутри процессора императивно, железо функционально тоже только условно: есть скорость распространения сигнала.
В идеале от императивности нужно бы отказаться вообще,
Это невозможно: все вокруг императивно. Комбинационные схемы в ЦП переключаются императивно, что приходится выравнивать тактированием. Даже если вы возьмете аналоговый компьютер, все равно столкнетесь с проблемой выравнивания фаз.
Vjatcheslav3345
09.07.2016 21:27"тащить за руку в библиотеку и показывать как там картотека устроена!"
Лучше показать ученику список ссылок на текст какой ни будь интересной работы — например, подойдет список алфавитного указателя из работы киноведа, посвященной предпоследней версии самого крутого боевика, который идет сейчас в кинотеатрах — там будет понятно, что список страниц со словом "терминатор", "чужой", "клоны", ну, или для девочек — "принцесса Лея" — это последовательный список последовательно (но не рядом стоящих в книге) идущих страниц, где это слово упоминается и страницы различаются по специально предназначенному для этого элементу оформления — номеру страницы.
Чем интереснее и оригинальнее будет Вами придуман пример — тем меньше вам придется вести в библиотеки учеников, только для того, чтобы показать скучнейшую вещь на свете — картотеку, и тем больше времени будет потрачено на программирование и на интереснейшие дискуссии — из области искусств и, опять таки — программирования.khim
09.07.2016 21:44Лучше показать ученику список ссылок на текст какой ни будь интересной работы — например, подойдет список алфавитного указателя из работы киноведа, посвященной предпоследней версии самого крутого боевика, который идет сейчас в кинотеатрах — там будет понятно, что список страниц со словом «терминатор», «чужой», «клоны», ну, или для девочек — «принцесса Лея» — это последовательный список последовательно (но не рядом стоящих в книге) идущих страниц, где это слово упоминается и страницы различаются по специально предназначенному для этого элементу оформления — номеру страницы.
Попробуйте — и вы поймёте что половина учащихся решат, что список — это упорядоченное подмножество, а другая половина — осознает, то «это что-то похожее на списк литературы», но будет считать что нет ничего страшного в том, чтобы записать пару ссылок в один элемент типа «Node*» (если мы в C) или "^Node" (если у нас Pascal). И будут обижаться что компилятор какой-нибудь «ну такой простой вещи» не понимает (например что не стоит терять старое значение, если оно нам ещё нужно).
Чем интереснее и оригинальнее будет Вами придуман пример — тем меньше вам придется вести в библиотеки учеников, только для того, чтобы показать скучнейшую вещь на свете — картотеку, и тем больше времени будет потрачено на программирование и на интереснейшие дискуссии — из области искусств и, опять таки — программирования.
Дискуссии можно потратить на всякие самые разнообразные темы, но пока обучающийся не поймёт, что компьютер — болван и «не понимает» ничего — успеха не будет.
P.S. Есть такая присказка: хуже дурака может быть только дурак с инициативой. Так вот компьютер — не просто дурак, а законченный кретин. А современные языки не делают его умнее, но дают ему возможность «проявлять инициативу». Чем они и опасны для обучения…vlad72
10.07.2016 09:49khim
В общем-то Ваш подход понятен и где-то даже оправдан: этакое глобальное научное образование, которое вполне может идти и от сложного к простому. Если ученик в него «вписывается», то все ОК, но дело в том, что далеко не все смогут это сделать (так как это сложней изначально), поэтому отсеятся даже те, кто смог бы кодить на более низком уровне. Например далеко не все нормальные прогеры на ООП любят ФП. Что-ж им уходить с этой работы теперь?
Есть такое распределение в виде пирамиды: внизу кодеры (их много), по-середине программисты (их меньше), на самом верху разработчики языков и парадигм (их мало). И все они полезны. Кто где, становится понятно через время (от года до пяти как минимум) — поэтому обучать лучше снизу вверх.
Как то так…
ZaEzzz
10.07.2016 23:12Не путайте функциональность мозга с мыслительным процессом.
Мозг — жесткая функциональная асинхронщина.
Человеческое мышление — тотальная императивность.
VolCh
10.07.2016 12:41Переменные и указатели (или как они там называются в Паскале — ссылки?) многие старшеклассники осваивают с большим трудом, если вообще осваивают. Им мешает, как ни странно, знание математики, алгебры. Запись типа x = x + 1 вводит их в ступор.
khim
10.07.2016 17:31+1Именно так. И они же — с лёгостью проходят через RL. Но нет, программисты со стажем будут продолжать рассказывать сказки о том, что ООП — это очень просто, а функциональное программирование — это ужас-ужас… потому что в противном случае встанет вопрос об их собственной профпригодности.
В общем истина, высказанная Планком о физике верна и для программирования: Не следует думать, что новые идеи побеждают путем острых дискуссий, в которых создатели нового переубеждают своих оппонентов. Старые идеи уступают новым таким образом, что носители старого умирают, а новое поколение воспитывается в новых идеях, воспринимая их как нечто само собой разумеющееся.webkumo
10.07.2016 22:26У вас, видимо, есть статистически наработанный опыт, чтобы утверждать, что RL более понятен чем императивные конструкции языков программирования? (ООП нужно давать отдельно от программирования и давать по рукам тому, кто даёт их одновременно)
khim
11.07.2016 13:00Научных монограмм у меня нет, но так как RL реально использовался для преподавания в школе (я сменил место жительства, так что лет 10 не преподавал — может и до сих пор используется), то могу сказать, что у людей не имеющих опыта программирования RL вообще идёт «в лёгкую» (у них не возникает ненужных вопросов и за один урок они изучают весь RL, а на следующем — уже можно на основе RL'я что-то строить и обсуждать).
У детей с опытом общения с BASIC«ом или, в более новое время, с C# возникают проблемы, но обычно они их быстро преодолевают (очень сильный стимул: им стыдно, когда люди, которых они считают „менее продвинутыми“ их обгоняют).
А вот у профессиональных программистов (на императивных языках, Scheme'ры, понятно, в восторге) — воникает отторжение. Причём не на уровне „ничего не понятно“, а „ну, это слишком сложно, лучше сначала с циклов начать“.DrPass
11.07.2016 13:54+1> А вот у профессиональных программистов (на императивных языках, Scheme'ры, понятно, в восторге) —
> воникает отторжение.
Я вам легко скажу, почему: профессиональный программист знаком с правилом бритвы Оккама. Ребенку-то всё равно. Ему объяснили абстракцию, он её понял и дальше использует. Профессиональный программист же видит _еще одну абстракцию, которая делает всё то же самое каким-то другим путем_, и первая мысль, которая его посещает, звучит как: «Нафига все эти навороты?» Кроме того, профессиональный программист знает, как обычно рождаются многие такие языки: сидит вечером другой скучающий программист, и думает, как бы ему сделать язык, непохожий на С++, чтобы обязательно была новая, интересная, свежая концепция. И начинает творить, для самого себя, чтобы было прикольно. А потом, если pet-проект доживает до стадии готовности, выводит это в свет.
И еще один момент есть: несмотря на обилие функциональных языков, с большей вероятностью обучаемый в жизни столкнется с обычным императивным языком. И поэтому нет смысла что-либо в этом менять. Надо будет что-то функциональное — выучит сам.DrPass
11.07.2016 14:03> сидит вечером другой скучающий программист, и думает, как бы ему сделать язык, непохожий на С++,
> чтобы обязательно была новая, интересная, свежая концепция
Чтобы избежать недопонимания — собственно, это не камень в огород функциональных языков, а просто фича — так многие языки рождаются :)
VolCh
11.07.2016 16:41Надо будет что-то функциональное — выучит сам.
Так в том-то и дело, что обойтись императивным языком можно, наверное, всегда (как и функциональным — они тюринг-полные). Если обучить функциональному, то императивный язык точно понадобится, человек его выучит и будет знать две парадигмы. А если человеку, знающему только императивную попадётся задача, которую эффективнее решить с функциональной парадигмой, то скорее всего он обойдётся императивной, а не будет учить функциональную.
fetis26
08.07.2016 13:18-1А зачем вообще программирование учить в школе? Откуда этот тренд, что все должны программировать.
DrPass
08.07.2016 13:41> Откуда этот тренд, что все должны программировать.
А нет никакого тренда. В школе не профессиональная подготовка ведется, а дается понимание, что есть, как оно устроено, и что выбирать в дальшейшей жизни.
ru_vlad
08.07.2016 14:56Соглашусь, НО есть такая гадость как ОГЭ ( 9 классы) и ЕГЭ (11 классы) если в 9 там минимум, то в 11 не зная программирования хорошо не сдать. Это если еще не вспоминать про «школьные олимпиады по информатике», там чистое программирование.
Так что если человек собирается в технические вузы то данное ему необходимо.
VolCh
08.07.2016 15:12+2А зачем вообще биологию учить в школе? Откуда этот тренд, что все должны биоложить?
DmitryMelnyk
08.07.2016 20:59-1Раз такая тема пошла то стоит отметить, что в школе учат кучу всего но редко учат главному: как строить крепкую семью, уметь ладить с людьми: в коллективе на работе и с близкими, развивать своё здоровье, уметь решать задачи, не бояться трудностей, а тему как эффективно обучаться вообще не поднимаем.
DrPass
08.07.2016 23:05+1> как строить крепкую семью, уметь ладить с людьми: в коллективе на работе и с близкими,
> развивать своё здоровье, уметь решать задачи, не бояться трудностей
А родители ребенку тогда зачем? Кормить его тоже в школе можно :)DmitryMelnyk
09.07.2016 01:17если в школе не укрепляют здоровье, не учат способствующему жизни знанию, не гибкости и пыту мудрости, не знанию того, что творится под носом, а учат информации об абстрактных вещах то зачем тогда школа?! Ведь потом всему этому они будут обучаться стихийно в курилках, пьянках, семейных скандалах, когда будут нападать на своих родителей и отбиваться потом от своих же детей…
DrPass
09.07.2016 22:24> если в школе не укрепляют здоровье
Не укрепляют. Здоровье укрепляют в санаториях.
> не учат способствующему жизни знанию
Учат, но не как строить семью и как ладить с людьми.
> не гибкости и пыту мудрости
Этому вообще никто не учит. Это человек сам приобретает. Или не приобретает.
> не знанию того, что творится под носом
А что под ним творится?
> зачем тогда школа?
Затем, чтобы ваш ребенок умел читать, писать, считать, и обладал набором базовых знаний, чтобы дальше определить свою профессию и занять место в обществе. Как правильно жениться и какой коньяк лучше пить, эти вопросы находятся вне компетенции школы.
MacIn
08.07.2016 23:44как строить крепкую семью, уметь ладить с людьми: в коллективе на работе и с близкими
Это слишком индивидуально, такому не научишь.
развивать своё здоровье
Не только учат, но и непосредственно развивают: внезапно, физкультура.
уметь решать задачи, не бояться трудностей
Частично это делает литература, но она изрядно устарела, поэтому эффект мал.
а тему как эффективно обучаться вообще не поднимаем.
У нас учили разным приемам в рамках уроков психологии.
DmitryMelnyk
08.07.2016 21:10Каждый программист считает, что программированию должны обучать детей в школе потому, что это вправляет мозги и учит решать конкретные задачи.
Каждый шахматист считает, что шахматам необходимо обучаться в школе так как это структурирует мышление, учит смотреть на ситуацию с разных углов.
Каждый преподаватель боевых искусств считает, что этому должны учить детей в школе не потому, чтобы морды бить людям, а потому, что боевое искусство помогает социализироваться, научиться ладить с людьми, адаптироваться в коллективе.
Список можно продолжить…
Я считаю, что в школе нужно больше учить не знаниям, а навыкам(учиться, ладить в коллективе с людьми, строить крепкую семью и т.д.), которые помогут в жизни: если знания бесполезные то они забудутся, а мастерство, как говорится, не пропьёшь)fetis26
08.07.2016 21:48Я программист и я так не считаю. Поэтому отнюдь не каждый. А вот навыки работы с компьютером и понимание как работают современные технологии я думаю преподавать нужно. Многие вообще базовых принципов не знают
0xd34df00d
10.07.2016 01:14Я программист, и я считаю, что вправляет мозги математика, а не программирование. Причём, не бесконечное зазубривание тригонометрических формул, а что-то чуть более красивое. Ну, теория групп, например.
И жизнь моя стала краше, когда я познакомился с теорией групп на первом курсе вуза. И жизнь моя стала краше, когда я познакомился с чистым функциональным языком программирования.
Правда, ладить с людьми в коллективе это меня не научило, скорее наоборот :(
Кстати, я размножаться не хочу и считаю, что для меня семья — не что-то хорошее. Чему меня должны были учить на предлагаемых вами уроках?
evocatus
08.07.2016 01:32+1Сам изучил и попробовал немало языков, а сейчас в добавок к основной работе преподаю в школе информатику.
Моё мнение: первым нужно учить Си. А вторым мультипарадигменный язык типа Lua или Python. 2 самые лучшие руководства по языкам программирования, которые я брал в руки это Керниган&Ритчи © и Иерусалимски (Lua).
За упоминание С++ или Java сразу бить линейкой по рукам. Школьники, которые не хотят думать, очень падки на сказки про «универсальный язык». Потом превращаются в интеллектуальных инвалидов — остатки умения строить архитектуру программы и алгоритмов рассеиваются и они начинают как обезьяны перетаскивать элементы на формы в VIsual Studio или C++ Builder, вообще не понимая что они делают. Вместо того, чтобы разобраться с GTK а, может быть, даже SDL2.gaki
08.07.2016 04:46+4Вот, кстати, да — тоже хотел написать что-то в этом духе. Лучше не начинать обучение программированию с C++/Java/Javascript — эти индус-триальные уродцы появились на свет в результате ректального изнасилования их родителей чуждыми им парадигмами. Рано или поздно освоить, как минимум, один язык из этой троицы таки придётся, но лучше поздно, иначе можно навсегда остаться ментальным инвалидом. Вспоминаю, как сам когда-то пытался понять некую простую концепцию вроде map/reduce/filter — вроде, и понимать-то нечего, да вот беда: объяснение давалось на примере STL-библиотеки, обрабатывающей STL-контейнеры. До сих пор икаю и глаз дёргается.
Начинать, в нынешних реалиях, лучше действительно с С и Питона (по-моему, можно параллельно учить оба сразу) — Питон показывает, как быстро и кратко сделать что-то на высоком уровне, а С — как это всё работает на низком уровне. Потом от С можно пойти в сторону Ассемблера, а от Питона — в сторону Scheme. По-хардкору, можно бы и начать сразу с Ассемблера и Scheme, но они слишком сильно оторваны от повседневной реальности.webkumo
08.07.2016 09:50+1Мне вот всё интересно, чем же вам эти языки-то не угодили?
C++ на базовом уровне — достаточно простоя язык, если не вдаваться в дебри шаблонизаторов и «бить линейком по рукам» за ифдефы — на базовом уровне язык по сложности/эффективности будет мало отличаться от C.
Java — промышленный язык который старательно следует парадигме «написано однажды — запустится везде» (да, не всё так гладко, как хотелось бы, но тем не менее). Чистый несложный язык, пытающийся в важных местах контролировать программиста и дающий при этом максимум свободы (наговнокодить можно… ну так и на C можно так наговнокодить!). Конечно есть вопрос к пониманию работы с памятью… но в конечном счёте и здесь всё не бесплатно, поэтому концепцию управления памятью учить приходится.
JavaScript — мощный быстрый язык позволяющий буквально всё… Такой язык без жёсткого контроля со стороны давать действительно нельзя, но вот чистую алгоритмику на нём изучать — вполне нормальное явление.
В общем, простите, но у меня сложилось впечатление, что «неасилил, потому и ругаю». Я бы тот же C без хорошего преподавателя давать обычным школьникам не решился. Нахрена нам ещё одни говнокодеры кривых драйверов?DistortNeo
08.07.2016 09:54+2Ну да, если изучать C++ как C с классами — будет просто. Главное, не пытаться потом бить пяткой в грудь, утверждая, что знаешь C++.
> JavaScript — мощный быстрый язык позволяющий буквально всё…
Это вы так пошутили? Это язык без стандартной библиотеки — каждый вынужден использовать сторонние модули. Быстрый — у интерпретируемых языков нет затрат на компиляцию, но скорость выполнения очень низкая. Буквально всё, но только в пределах песочницы, в которой он запущен.
gaki
08.07.2016 10:54+2Если не вдаваться и мало отличаться от С, то это и будет, в сущности, С. Такой нормальный кроссплатформенный высокоуровневый ассемблер. Мне, кстати, не кажется таким уж ужасом использовать С++ как чуть более продвинутый С, хотя, возможно, тут я неправ. А вот использовать С++ для изучения более высокоуровневых концепций — зло. Начнёт студент изучать ООП — он также должен будет изучить всю сиплюсплюсную хрень вроде того, как, когда и в каком порядке вызываются чистые виртуальные приватные конструкторы базовых классов. А так же как, когда и почему они не вызываются. Начнёт студент изучать обработку структур данных — он тут же запутается в угловых скобках, шаблонах, контейнерах, итераторах и компараторах, словно в рукавах смирительной рубашки. Вот скажите, ну зачем, например, для изучения алгоритмов нужно знание того, что ++iterator работает быстрее чем iterator++? Да те же пресловутые указатели, понимание которых считается чуть ли не врождённым дарованием — ну что, казалось бы, сложного: выделил память, попользовался, освободил. А то, что синтаксис С++ в этом отношении запутан и противоречив.
Java — промышленный язык, который старательно держит программиста за идиота, страдающего ООП головного мозга.
Касательно того, что не так с JavaScript… было бы, всё же, некоторым преувеличением ответить «всё!», но по-моему, гораздо быстрее выйдет перечислить не «что не так с JavaScript», а «что так с JavaScript» :)
Что касается «асилил/ниасилил». Я, конечно, не Линус Торвальдс, но более-менее освоил С++ уже довольно давно, на данный момент это мой основной рабочий язык. То, что до сих пор иногда приходится озадаченно чесать репу, потому что не знал, что некая фича С++ работает именно так, как работает — наверное, характеризует негативно до некоторой степени и мои умственные способности тоже, но нам же в программировании нужны не только абсолютные гении, правда?
Может показаться, что я считаю себя сильно умнее создателей С++, Java и JavaScript. Это не так — я понимаю, что у создателей всех трёх этих языков были вполне объективные причины сделать их именно такими, какие они есть. Более того, эти причины мне, в общих чертах, известны. Еще более того, именно по этим причинам данные три языка и стали настолько популярны. Если так, почему не изучать программирование исключительно на них? Я бы воспользовался аналогией из статьи Брукса «No silver bullet»: он использует понятия «essential complexity» и «accidental complexity». Я не уверен, как это красиво перевести на русский, поэтому оставлю, как есть. «Essential complexity» — это сложность, собственно, самой задачи. «Accidental complexity» — это сопутствующие сложности, связанные со средствами, используемыми для решения этой задачи. Перво-наперво надо учиться справляться с essential complexity, а если мы для изучения программирования выбрали C++/Java/JavaScript, получится, скорее, наоборот.webkumo
08.07.2016 12:14Ну ООП изучать на базе C++, не планируя стать программистом и сделать его своим основным инструментом — это с головой не дружить, согласен. Кстати, описанные проблемы C++ результат того, что единого управляющего развитием центра там нет. Впрочем и бонусы он извлёк из этой же ситуации…
Java — действительно промышленный язык. Который (при незначительном повышении знания) позволяет очень (слишком) многое программисту. Единственное, что он не даёт делать напрямую — управлять памятью. Впрочем да, писать в парадигмах отличных от ООП в Java сложно (хотя процедурный реализуем, да и элементы функционально появились)… Вот только зачем в Java писать в иных парадигмах? Это не минус, это базовый функционал. Хотите функциональщину — берите Scala (только почему-то она не смогла «победить Java»… да и вообще в последнее время некоторое охлаждение к ней идёт). Хотите другую парадигму — ради бога, используйте любой интересный вам язык.
С JavaScript, как с языком для обучения программированию что-то не так? Простите, но это бред. Проблема этого языка — как раз в том что он предельно простой (но с подводными камнями, и уютно разложенными граблями). А из-за того, что он простой к нему лезут те, кто и алгоритмов-то не понимают! В Серьёзной Промышленной Эксплуатации конечно эти все грабли и подводные камни всплывают. Но это ведь уже другая проблема — сперва нужно добиться понимания алгоритмизации от человека. Ну и напоследок отмечу — язык (сам по себе) JavaScript вполне нормальный… мешает ему то же, что и c++ — много плохо совместимых реализаций (впрочем здесь заметны некоторые улучшения) и то, что пишут на нём люди, не понимающие этого языка (порой — от слова «совсем»).
Но речь-то о том, что «Лучше не начинать обучение программированию с C++/Java/Javascript» (окончание этого предложения вообще фееричное...). А начинать, на самом деле, можно на любом языке. Потому что первая задача — познакомить человека с «алгоритмами» и «структурами данных».
В плане обучения программированию «Accidental complexity» — это про сложность написания простых программ (у Java с этим есть небольшие проблемы — всё-таки «хелловорлд» получается достаточно многословный). И для простых программ все обиженные вами языки подходят (равно как и для, собственно, обучения программированию).
А вот дальнейшее обучение (когда человек уже решил стать программистом) должно больше опираться на сферу, в которую хочет войти программист. Просто потому, что это накладывает серьёзные ограничения-фильтры на список выбираемых языков. Ну не получится у вас писать программы для большинства МК на Java/JavaScript (равно как и драйвера устройств). Не получится у вас для веба писать на C/C++ (хотя трансляторы есть… но лучше б их не было). Не разумно писать enterprise-класс приложений на c/c++ (слишком дорогая поддержка и написание). Безусловно я сейчас очень условно поделил ниши и есть «протечки», но в целом ситуация близко к описанной мной ситуации. И тут мы приходим к тому, что если человеку хочется делать веб, то ассемблер ему вообще никуда не упёрся (равно как и C)… ну и зачем их изучать? Может лучше сразу js? Только, так сказать, «на берегу» объяснить, что подводных камней — море. И учить потроха языка придётся глубоко. А помимо языка ещё нужно будет учить либы и фреймворки. При этом в вебе сейчас дикая скорость развития.DrPass
08.07.2016 12:25+4> Проблема этого языка — как раз в том что он предельно простой
Да нифига он не простой. Он, как бы это точнее назвать, анархический. Когда вы берёте для преподавания обычный императивный язык со строгими правилами, вы рассказываете про типы переменных, про последовательность выполнения кода, и это как раз логично и легко для понимания. В случае JavaScript у вас нет жестких рамок, и многие студенты просто не могут уловить логику в создании программ на нём.
VolCh
08.07.2016 12:27+1Как раз для веба изучение Си может быть полезно. Вообще придерживаюсь мнения, что хороший программист знает (хотя бы поверхностно) внутреннее устройство используемых инструментов (в частности трансляторов), может, как минимум, залезть в исходники и попытаться понять, почему его программа ведёт себя не так как он ожидает.
evocatus
08.07.2016 12:29+1== и ===
NaN, которое является числом, но не равно самому себе
И это только первое, что пришло в голову хотя я Js почти не знаю
Я категорически против того, чтобы этим говном пудрить мозги новичкам в программировании.
То, что эта кривая поделка стала так популярна — говорит не о том, что она хороша, а о том, что индустрия часто поощряет не самые лучшие технические решения, а непонятно что.evocatus
08.07.2016 12:37+1Я не сомневаюсь, что Брендан Эйк профессионал высокого класса. Но когда он создавал JS, это явно был безответственный поступок. Сделать ЯП за 10 дней на коленке… Похоже, он в тот момент сам всерьёз не относился к этому поделию. Возможно, планировал в скорости заменить его следующей версией. Но кто же знал, что оно так разойдётся.
Отсюда урок: 7 раз отмерь, 1 раз отрежь, особенно если проектируешь систему (т.е. нечто, что будет работать в связке с другими продуктами или использоваться другими людьми). Протоколы взаимодействия, формат файлов, архитектура программы — это самые важные вещи. Всё остальное можно переделать.
gaki
08.07.2016 12:43+2>… единого управляющего развитием центра там нет
Вот сейчас членам «The C++ Standards Committee» обидно было…
Проблемы и бонусы С++ — результат того, что он развивался эволюционно, мучительно пытаясь сохранить обратную совместимость. Был язык С, быстрый, «близкий к металлу», при этом достаточно переносимый. Захотелось объектов. Объекты были уже, допустим, в Смоллтоке — но Смоллток не нужен. И что-то совсем новое, куда объекты хорошо впишутся, мы тоже не хотим. А хотим, чтобы у нас старое на С тоже продолжало работать. Давайте введём объекты в С! К сожалению, физиологическое отверстие, через которое внутрь С можно ввести объекты, только одно — заднепроходное. И вот тут метафора с ректальным изнасилованием мне кажется очень точной. Дальше — больше: хотим обобщённое (или как его там) программирование. Оно уже есть, допустим, в Лиспе — но Лисп не нужен. Давайте введём в С++! К сожалению, физиологическое отверстие для введение осталось всё то же… ну вы понели. Тем не менее, в результате мы и объекты, и обобщённое программирование худо-бедно имеем, язык развивается, программисты не разбегаются кто на Лисп, кто на Смоллток, уже написанный код поддерживается, и вообще жизнь прекрасна. Попытки запилить вместо этого что-то новое, концептуальное и красивое, время от времени предпринимаются, но по степени своей успешности напоминают попытки перевести человечество на язык Эсперанто :)evocatus
08.07.2016 12:52Опять эти сказки про универсальный язык.
Инструмент нужно выбирать под задачу. В программировании есть свои специализации (highload, bigdata, desktop, server backend, server frontent, embedded, machine learning,… ) и если ты посмотришь внимательно на все эти группы технологий, то там давно уже «универсальный» С++ вытеснен или активно вытесняется более совершенными (хоть и узкоспециализированными) инструментами0xd34df00d
10.07.2016 01:18Я пишу немножко хайлоад, немножко бигдата, немножко машин лернинг, ну и периодически для хобби под десктопы пишу.
Почти везде у меня основным языком C++. Только в ML немножко хаскеля, да. Что я делаю не так?DrPass
10.07.2016 09:03> Что я делаю не так?
Прогуливали в институте лекции по статистике :) Иначе понимали бы, что ваш личный пример ничего не значит.
webkumo
08.07.2016 15:16Вот так и хочется ответить всем и разом… но у меня лимит, поэтому буду отвечать всем здесь.
Гугл такую структуру не нашёл. Комитет стандартов C++ в ISO — да есть. Здесь две проблемы — очень много Undefined Behavior (оставляется на откуп компиляторам), и вторая — комитет явно имеет проблемы в однородности — раз уж с модульностью прокатило в текущем стандарте. Так что… не на что обижаться-то.
Вот Java действительно развивалась эволюционно. Вероятность того, что код, написанный для java 1.2 сломается в JVM 8ой — весьма невелика. Единственное, что потребуется — притащить с собой классы, которых уже нет в стандартной библиотеке.
Впрочем для меня это не только плюс, но и жирнющий минус — слишком много это за собой тащит проблем.
DrPass «многие студенты просто не могут уловить логику в создании программ на нём» стоит переписать как «многие преподаватели просто не умеют объяснять алгоритмы, поэтому им обязательно требуются костыли строгой типизации». Чтобы вы не думали, что я наговариваю на какой-либо язык — основная моя разработка крутится в Java, но приходится также активно использовать и JS (ибо почти фуллстек с уклоном в бекэнд). И динамическая типизация писать алгоритмы не мешает совершенно. Вот для «писать надёжно» и прочих фишек требуется дополнительные усилия (линтер, статический анализ кода, стайл-гайды, ...). А вот базу (алгоритмы) на JS писать ничто не мешает.
VolCh Изучение C — сомнительно. Веб слишком далёк от железа, чтобы глубоко в железо погружаться для его изучения… Хотя если есть желание писать в том числе VM исполняющую код — тогда действительно нужен. И да, я под вебом подразумеваю только UI (брауезрную) часть. Для этого веба полезней знать принципы работы с памятью в managed VM.
evocatus и с какой вероятностью студент/школьник напорется на проблему с ==/=== или с NaN? Особенно если он _не_планирует_ стать программистом? (Впрочем мне легче понимать разницу в проверках эквивалентности — в Java == и .equals() тоже имеют существенные различия в работе)
PS вообще же, программирование (в школах) лучше давать на визуальных языках типа скретч (https://scratch.mit.edu/).
В институтах на непрофильных специальностях — скриптовой, и только для тех, кто планирует стать разработчиком есть смысл начинать с компилируемых (возможно даже с управлением памятью).
Но перед этим всё-таки создать нормальный курс «ввод в специальность» в котором хоть как-то разъяснить разницу между языками — пусть сразу сами выберут (всё легче будет изучать — мотивация будет эффективней).
И да — паскаля в этом списке нет, т.к. имеет слишком малую распространённость… Да и эффективность современного паскаля под большим вопросом.VolCh
08.07.2016 15:22Изучение C — сомнительно. Веб слишком далёк от железа, чтобы глубоко в железо погружаться для его изучения… Хотя если есть желание писать в том числе VM исполняющую код — тогда действительно нужен. И да, я под вебом подразумеваю только UI (брауезрную) часть. Для этого веба полезней знать принципы работы с памятью в managed VM.
Я не только (и даже не столько) браузерную часть имею в виду, а, скорее, бэкенд. И не «виртуальный». Если о виртуальной машине речь (Java, .Net и т. п.), то изучать надо её, а не Си.
eydemidov
08.07.2016 20:18Что касается «асилил/ниасилил». Я, конечно, не Линус Торвальдс, но более-менее освоил С++ уже довольно давно, на данный момент это мой основной рабочий язык.
Иронично — Линус говорил, что C++ — ужасный язык, а люди, использующие его, лучше бы никогда не подходили к ядру Линукса ;)
dns78
08.07.2016 11:52-1Вы уж извините :)
> JavaScript — мощный быстрый язык позволяющий буквально всё… Такой язык без жёсткого контроля со стороны давать действительно нельзя, но вот чистую алгоритмику на нём изучать — вполне нормальное явление.
У Вас ошибка в слове JavaScript. Судя по контексту, Вы имели в виду ассемблер.dns78
08.07.2016 12:01PS: Никакого жесткого контроля за обучением не нужно — кидаешь, либо выплывает, либо нет. Причем желательно в операционной системе, где нет никаких песочниц, контроля операций с памятью и дисковых операций и тд. Пока человек не ошибется, например, инкрементировав не тот регистр (или переменную, не суть), и не пропишет аккуратно весь диск нулевыми секторами через дорожку вместо того, чтобы заполнить один цилиндр — он ничего не понял. Пока не поиграл сам с собой в памяти приложения в core wars — он ничего не понял. Пока он не прострелил себе ногу — он ничего не понял. Пока он не научился писать классы и имплементировать ООП или иную ООП головного мозга на любом языке, который как бы это все не поддерживает — он ничего не понял. Все это имхо, кмк, etc.
gaki
08.07.2016 12:07+1PPS: И, желательно, сразу куда-нибудь программировать АЭС или систему управления межконтинентальными баллистическими ракетами. Пока он не сжёг пол-континента в пламени ядерного огня — он ничего не понял.
dns78
08.07.2016 12:20Ok, я недостаточно внятно выразился. Песочницей в данном случае выступает своя машина.
DrPass
08.07.2016 12:02> Судя по контексту, Вы имели в виду ассемблер
Вообще, судя по контексту, это был Паскаль :) Я бы не стал пытаться преподавать чистую алгоритмику на ассемблере, где две трети операций будут связаны не с выполнением алгоритма, а с обеспечением костылей «где и как сохранить данные». Да и мощным я бы его постеснялся назвать. Мощность языка определяет производительность программиста, а не программ.dns78
08.07.2016 12:06Я лишь старался подобрать язык, имеющий примерно столько же символов в названи, что и js :)
webkumo
08.07.2016 13:22Поясню, раз ввёл в заблуждение общими терминами…
Мощный язык — язык, позволяющий реализацию достаточно широкого спектра алгоритмов. При этом для популярных алгоритмов известны готовые решения.
Быстрый язык — язык, минимально втыкающий палки в колёса при попытке написать небольшую программку (мы ведь про базовое обучение — там нет места крупным проектам).
Надеюсь больше не будет недопонимания в смысле слов, который я вкладывал в фразу.
PS хабр меня таки вынудит написать статью… раз в час комментировать… тяжело…DrPass
08.07.2016 13:46> Мощный язык — язык, позволяющий реализацию достаточно широкого спектра алгоритмов
Дык, любой Тьюринг-полный язык позволяет реализовать какие угодно алгоритмы. Мощность языка определяется не этим, а тем, сколько времени потратит программист на реализацию. Чем в языке больше разнообразных конструкций, тем он мощнее.
> Быстрый язык — язык, минимально втыкающий палки в колёса при попытке написать небольшую программку
А подавляющее большинство языков не создают сложностей с небольшими программами :) Вопрос больше лежит в области наличия библиотек под типовые задачи.VolCh
08.07.2016 13:59Мощность языка определяется не этим, а тем, сколько времени потратит программист на реализацию. Чем в языке больше разнообразных конструкций, тем он мощнее.
Не совпадающие определения. Если конструкций слишком много, и области их применения пересекаются, то можно потратить много времени в процессе выбора а какую же конструкцию использовать. Грубо, то ли от абстрактного класса наследоваться, то ли интерфейс реализовывать.DrPass
08.07.2016 14:19Серьезно, вы много тратите времени на дилемму, реализовывать интерфейс или наследоваться от абстрактного класса? :) Я думаю, не ошибусь, если скажу, что с тех пор, как вы это сделали несколько раз, вы перестали над этим задумываться. Если вы программируете, а не изучаете новый для вас язык, то вы имеете понимание, какую конструкцию где лучше применять. Вы имеете набор привычных для вас паттернов разработки, и таких ситуаций у вас просто не возникает.
VolCh
08.07.2016 15:13До тех пор пока не начинаешь поддерживать чужой код, где паттерны несколько другие. А то и свой, но времён других паттернов.
evocatus
08.07.2016 12:24+1А на кой ляд нужен «C++ на базовом уровне»? Если он «по сложности/эффективности будет мало отличаться от C».
Да не будут школьники программистами на Си только потому что его изучали на уроках. Большинство вообще не будут программистами, а те, кто будут, успеют изучить ещё немало новых языков и технологий прежде чем начать профессиональную карьеру. Зато понимание того, что такое «выстрелить себе в ногу» в массивах и указателях будет очень полезно. Более менее адекватное представление о том как вообще выполняется программа на компьютере, способность оценить более мощные языки.
ZaEzzz
08.07.2016 13:36+2Мне кажется, лучше начать изучение программирования с алгоритмов и объяснения того, что компьютер — это не крутой магический ящик, который все может, а наитупейшая коробка с феноминальными памятью и скоростью вычислений.
Помню свой первый урок в пятом классе на эту тему: учитель на себе продемонстрировал как «думает» машина — нам надо было давать ему команды, чтобы он встал, взял мелок и начертил на доске линию с одного края до другого. С его фразами «а это как?» или «я этого не знаю и пока не умею» мы поняли что такое инстукции, переменные, константы, циклы и условия. Следующим нашим шагом стало понимание алгоритма работы наипростейшего процессора, и только потом перенос его на QBasic (я ни коем образом не говорю, что сначала надо именно его изучать). Все было интересно, сразу понятно зачем оно нужно и уже легко выполнимо. А вот второй группе класса не повезло — их сразу посадили за компы рассказывая что такое монитор, клавиатура, мышка, как ими пользоваться, как рисовать в паинте, вводить текст в ворде. Когда их посадили рисовать в QBasic'е все встали в ступор и возник вопрос: «А зачем это делать в бейсике, когда можно проще и быстрее нарисовать в паинте?»
В итоге, повторюсь, как мне кажется, упор нужно делать на развитие алгоритмического мышления и выбирать язык опираясь на различные данные — количество выделенных часов, возраст школьников, их скорость восприятия информации, требования к программе обучения итд. Боюсь, если бы мы в пятом классе начали с Си, то программа обучения очень сильно растянулась и у нас запал потух. В итоге мы бы к концу года знали синтаксис Си, но не более. А так первый год обучения информатике нам рассказал о том, что разработка — это очень интересно и дальше у нас понеслась родимая: паскаль и в концовке Си. На сегодняшний день я бы тоже паскаль заменил питоном, но все равно не стал бы ставить его (питон) в качестве первого ЯП для изучения. Почему мы сразу не сели за паскаль — я не знаю. Может из-за «лишних» обязательных требований самого языка, которые будут отвлекать от алгоритмов, а может еще что-то. Честно на знаю, благо и не преподаю.
P.S. Возможно сегодня для вовлечения в процесс можно использовать роботехнику, но я сам даже не щупал нынешних роботов, так что это только предположение.khim
08.07.2016 20:17Мне кажется, лучше начать изучение программирования с алгоритмов и объяснения того, что компьютер — это не крутой магический ящик, который все может, а наитупейшая коробка с феноминальными памятью и скоростью вычислений.
Проблема в том, что не все языки для этого подходят. Pascal, C, даже чёртов QBasic — подходят, а вот C# или Java — нет.
Потому что там — слишком много магии. Потому что если у вас что-то «рассыпается» — вы не понимаете что делать.
Это как если бы на уроках химии рассказывали не про ряд напряжений и электронные оболочки, а ограничивались бы тем, что показывали эффектные реакции и объясняли как производить дистилляцию и отжиг, но не объясняли — что там при этом происходит внутри.
Бред? Но почему тогда мы считаем что при обучении программированию можно обойтись формочками и крестиками-ноликами?michael_vostrikov
08.07.2016 20:27При обучении программированию учеников в школе вполне можно обойтись. На уроках программирования рассказывают, что происходит внутри на некотором уровне абстракции. Как и на уроках химии рассказывают о реакциях в терминах химии, а не квантовой физики.
khim
08.07.2016 20:41Как и на уроках химии рассказывают о реакциях в терминах химии, а не квантовой физики.
Всё-таки базовые вещи в программировании — это сложность вычислений и потребность в памяти, а не формочки. Так что «уровень химии» — это рассказ про разного рода КМП и Дейкстра.
А «формочки» — это уровень не химии, а алхимии. Слили два раствора вместе — хлопок и дым пошёл. Что там произошло внутри — нам неважно и неинтересно.
А уровень «квантовой физики» в программировании тоже есть — это разного рода эффекты, связанные с кешами процессора, MOESI протоколами и эффектами, которые из-за этого в программе возникают. Выделение/освобождение памяти — где-то на грани (все понимают, что malloc и free работают не константное время — но ситуации, где это важно и где нужно оптимизировал аллокатор — встречаются на практике не так уж часто). И тут я согласен — туда лезть по первости не нужно. Но если вы не понимаете, что работа со строками всегда чревата проблемами — то какой, нафиг, вы программист?ZaEzzz
09.07.2016 00:06Я честно не понимаю, что именно вы хотели именно мне сказать и почему спрашиваете меня о бреде с «формочками и крестиками-ноликами». Если вы придрались к тому, что пятиклассникам надо рассказать о том, что компьютер — это не магия, а тупица с феноминальными памятью и скоростью вычислений, то смею вас заверить в том, что бессмысленно им первым делом объяснять про нехватку памяти и сложность вычислений. Они же сами видят, что машина хранит тонны информации которая у них в голове не поместится и работает с ней в мгновение ока.
Я не согласен, что базовые вещи для начала обучения программированию — это сложность вычислений и потребность в памяти. Важно правильно выбрать уровень абстракции и дальше работать в двух направлениях: повышение уровня абстракции и более глубокое погружение в нюансы.
Хотел привести пример на самом простом — математические науки, но раз уж началась физика, то пусть будет она.
Надеюсь, согласитесь, что программа по физике для школы составлена адекватно? На нее и будем опираться. Если мне не изменяет память, то изучение физики начинается с механики: взяли уровень абстракции — абсолютно упругое тело, идеальные закрытые системы… Считается легко, видно явно. Дальше в течении нескольких лет с одной стороны идет углубление чуть-ли не до кварков, но с другой стороны начинается и повышение уровня абстракции до гравитационного воздействия планет и это еще без каких-либо легких тонкостей в виде коэрцитивной силы магнитомягких материалов или силы воздействия солнечного излучения на тела в нашей системе. В ходе обучения постепенно происходит доосмысление предыдущего материала и это нормальный адекватный естественный процесс.
В итоге в самом начале обучения программированию/информатике у школьников надо развивать алгоритмическое мышление и способность масштабировать мысли.
Насчет первого ЯП, на мой взгляд, это точно не Си. Скорее всего, это как начать изучение физики с уровня атомов и начать двигаться к квантам с галактиками. Или математику начать рассказом о мнимой единице.
Мне кажется, что лучше всего первым использовать ЯП, который они больше нигде использовать не будут. Попробовать, посмотреть, освоиться и перейти к нормальному.
На самом деле мне даже стало интересно, что вы сможете предложить в качестве старта для изучения 10-ти летним детям.khim
09.07.2016 01:04Хотите «абсолютно упругие тела» — возьмите какие-нибудь математические абстракции типа тех, которые я описывал выше.
Мне кажется, что лучше всего первым использовать ЯП, который они больше нигде использовать не будут.
Чем тот же Pascal не годится?
На самом деле мне даже стало интересно, что вы сможете предложить в качестве старта для изучения 10-ти летним детям.
Я вот вообще не уверен, что 10-леним детям нужно программирование преподавать. Физику — тоже не с первого класса в школе преподают.
Они же сами видят, что машина хранит тонны информации которая у них в голове не поместится и работает с ней в мгновение ока.
Вот это — и есть самая большая проблема современного, с позволения сказать, «обучения программированию». Когда для детей программируемые игрушки начинались с какого-нибудь Big Trakа, а програмиирование осваивалось на каком-нибудь Б3-34, то никаких иллюзий по поводу возможностей компьютеров не возникало. И было чётко понятно, что компьютер — это всего лишь «коробка с транзисторами». Пусть и побольше немного, чем калькулятор.
Сегодняшнее же обучение программированию пропускает кучу этапов и начинает с «магических заклинаний», так что с ограниченностью ресурсов человек сталкивается зачастую не в процессе обучению, а после нескольких лет работы. В результате — куча времени и сил уходит на то, чтобы отсеять этих горе-деятелей на собеседованиях и куча обид, когда студентку-разработчицу под iOS приходится отчислять за профнепригодность.ZaEzzz
09.07.2016 11:511. Вы честно не понимаете что описание .RL сложно для восприятия относительно Pascal'я? Там абсолютно другой слой восприятия. Простота и краткость описания не обязательно идут в ногу.
2. Где я утверждал, что Pascal не годится?
3. А я уверен, что в наш век уже нужно давать азы программирования для понимания самого направления наук. Самое позднее для старта — 8й класс. Мир вокруг нас слишком быстро меняется.
35 лет тому назад нас не окружали универсальные резво думающие машины. Да, надо дать понять, что компьютер — это буквально коробка с транзисторами, но дико резвая коробка, иначе это понимание ничего не даст — время уже не то. Работать напрямую с регистрами процессора и стеком памяти надо тому, кто выбрал для себя это направление. Вы же не удивляетесь, почему это на алгебре не рассказывают про функционал.
4. Может быть я вам открою тайну, но во всех областях деятельности:
А) Есть тонна нюансов познается в работе, а не на обучении. Вы собираетесь учить нюансам, которые с большой вероятностью не повстречаются людям? Лучше дать удочку с сачком, а не кормить ведром мальков.
Б) Есть люди, не способные осилить — они просто не способны думать в нужном направлении. Они просто пошли за розовыми мечтами или еще по какой причине оказались в области, но ошиблись.
Меня самого очень часто вводит в ступор отсутствия способности думать и всепоглощающая лень, но я не считаю, что нужно учить программировать на, грубо говоря, транзисторах — для этого более специализированное направление.
P.S. Насчет лени сразу вспоминается несколько моментов:
— Однажды разработчику JS на NodeJS надо было что-то написать на Си и он поинтересовался «а какой пакетный менеджер у Си?»
— Массовое поголовное использование парострочных (утрированно) готовых решений https://habrahabr.ru/post/280039/
— Использование внешней ссылки при импорте https://github.com/docker/docker/blob/master/cli/flagerrors.gokhim
09.07.2016 13:14Вы честно не понимаете что описание .RL сложно для восприятия относительно Pascal'я?
Понимаю. Знание Pascal'я скорее мешает, да. Потому RL обычно изучают до Pascal'я, а не после.
Там абсолютно другой слой восприятия.
Там простые математические термины. С которыми человек (если он не в начальной школе это читает) должен был ознакомиться на уроках математики.
Вы же не удивляетесь, почему это на алгебре не рассказывают про функционал.
Про функционал не рассказывают потому что это сложно сделать быстро. И про сапог Шварца не рассказывают примерно по той же причине. А вот про синусы-косинусы — рассказывают до сих пор. Потому что они учат работать с формулами.
Вот и RL — учит работать с функциями. Изучить его можно за пару уроков, написать простенькие программки (скажем расставляющие ферзей на доске 8x8) — ещё за пару (вначале нужно, конечно, числа реализовать, так как в RL их нету — но тут можно натуральными числами в единичной системе счисления ограничиться). А дальше — пишите хоть на JS, хоть на C++, это дело ваше.
Меня самого очень часто вводит в ступор отсутствия способности думать и всепоглощающая лень, но я не считаю, что нужно учить программировать на, грубо говоря, транзисторах — для этого более специализированное направление.
Специализированное направление — это если вы практически хотите добраться от транзисторов до JS. Но для практического занятия программированием самое важное, что нужно понимать — это то, что абстрации текут — и, к большому сожалению, протечки начинаются с самого-самого низу. Уже обращение в память «течёт», так как считать 100 байт подряд можно в несколько раз быстрее, чем 100 случайных байт, потом кеши добавляются и так далее — к моменту, когда мы добрались до JS у нас уже десятки слоёв абстракций — и все они могут нам аукнуться.
Да, надо дать понять, что компьютер — это буквально коробка с транзисторами, но дико резвая коробка, иначе это понимание ничего не даст — время уже не то.
А что случилось со временем? Какие принципиальные изменения произошли за последние 35 лет? Последнее поколение компьютеров — таки четвёртое. Всё, что произошло после — уже количественные изменения, не качественные.
А то, что коробка «дико быстрая» скорее усложняет процесс, чем упрощает его: в практических задачах она всё равно недостаточно быстрая зачастую, но если во времена когда калькулятор выполнял 10 операций в секунды вы осознавали это факт в первые пять минут общения с этой железякой, то сегодня вполне можно с этим столкнуться уже только став разработчиком… а в этот момент перестраивать своё мышление гораздо сложнее…MacIn
09.07.2016 15:41потом кеши добавляются и так далее — к моменту, когда мы добрались до JS у нас уже десятки слоёв абстракций — и все они могут нам аукнуться.
Самое неприятное то, что чем больше слоев абстракции, тем сильнее будут «протечки» и тем меньше у нас контроля над ними. Потому что, собственно, абстракция призвана нам его не дать. И протечка будет решаться либо силами самой абстракции — а значит, долго и плохо, либо с помощью использующего ее, и тогда абстракция перестает быть таковой.ZaEzzz
10.07.2016 23:10+1Никто не мешает отказаться от абстракции, если она мешает. Или вы предлагаете для передачи данных из формы в браузере на сервер использовать прямое управление напряжением на контактах ethernet-порта?
khim
11.07.2016 13:04Если бы абстракции мешали — их бы не использовали. И беда не в том, что они мешают и от них хочется отказаться, а в том, что когда у тебя 100500 уровней абстракции, и что-то работает не так, как ожидается, то заранее сказать на каком уровне — нельзя. Чем более глубокие абстракции, тем реже их «протечки» стреляют в реальном мире (они просто более оттестированы), но я реально сталкивался со случаем когда настройки памяти (вернее настройка prefetch'а) вытекали аж в JavaScript…
ZaEzzz
10.07.2016 23:061. .RL сложен для понимание не из-за Pascal'a а из-за базы знаний начальной школы.
2. Простые математические термины .RL дают нужный уровень абстракции для учеников 10-11 классов, но не для средней школы.
3. Вы предлагаете ученикам изобрести не велосипед, а способ как дышать — их уже научили, что есть минимум натуральный ряд (1 класс) и нужно поддерживать взаимосвязанность предметов. Ваше предложение больше подходить для институтов где говорят «забудьте все, что вы учили в школе».
4. Для практических знаний нужна тонна информации, а не только протечка абстракций (я понимаю, что это только один из примеров). Результативные практические знания получают не в школе или университете, а непосредственно на боевом опыте. Иначе пришлось бы учиться до 40 лет, а потом понять, что ты никому не нужен из-за того, что отстал на 20 лет.
Кстати, вы так часто ссылаетесь на этот блог как буд-то сами его ведете. Раскрою одну тайну по приведенной вами статье — она желтая и рассчитана на тех, кто не работает с сетью.
5. Что случилось со временем? На самом деле случилось самое страшное — мир информационных технологий изменился полностью.
Раньше компьютеры были доступны единицам, теперь ты можешь не подозревать о том, что купил новый еще один компьютер. Людям приходится подстраиваться под новые уровни абстракций взаимодействия с железом (благо в этом смысле эти абстракции стремятся к очеловечиванию, хоть я и дико против этого). Ни в одном направлении естественных наук не было столь дикого количества изменений за последние N лет, сколько в сфере информационных технологий. В то время когда физики/химики/биологи/etc живут в ожидании новых идей и открытий, мы живем в процессе фильтрации этих идей и открытий, иначе это просто невозможно переварить.
Я предлагаю изучать нужные современные абстракции. Как дальше развиваться — это выбор конкретного человека и специализации. Конкретные узкие проблемы должны решаться на месте/проекте а не на стадии обучения.
«То сегодня вполне можно с этим столкнуться уже только став разработчиком» — это и нужно осознавать только став разроботчиком.
Age1mar
08.07.2016 08:47+2Вы знаете, по своему опыту скажу что очень важно не останавливаться и не делать больших перерывов в изучении языков.
В институте я изучал C,C++,ASM,HTML,JAVA,SQL,1С. Параллельно работал сисадмином, и к сожалению знания по программированию я почти не применял. А зря. Сейчас со скрипом ( спустя 8 лет после окончания учёбы) пытаюсь навёрстывать упущенное.
И да, Pascal как 1й язык для меня был очень хорош.
Abhishek
08.07.2016 12:37-2Incredibly, Java never proposed study. Java is a language of industry No. 1 the last 10 years in the number of work projects and infrastructure. In addition, Java is very interesting both for its design language, such as Python and other languages ??openly borrowed the idea of ??libraries and fraymvorkov. From an academic point of view, the JVM is subject to the compulsory study of any programmer-theorist and / or performansnika. One JMM is worth something!You can visit our website for logo design,
www.logogoon.comZaEzzz
08.07.2016 14:03Бот обнаружен?
Зачем вы переводите чужие комментарии и добавляете ссылки не по теме? https://habrahabr.ru/post/304816/#comment_9691518
fetis26
08.07.2016 12:50Какой-то очень странный подбор языков, выбранный лишь потому что автор их учил. Некоторые вообще очень специфичные или нигде не используются. Нет функционального программирования опять же.
snuk182
08.07.2016 13:28+1Спасибо, на удивление годная статья, даже несмотря на непривычный выбор языков. Правда, вот эта фраза неистово повеселила:
> Objective-C – второй язык. Он представляет собой очень тонкий слой поверх чистого Си.
Все бы ничего, но потом с этого джедайского синтаксиса слезать больновато.
cosmrc
08.07.2016 13:52Но если вы хотите работать в индустрии, знать его нужно, так как альтернативы ему не предвидится.
Почему не предвидится? Например Rust. Очень лаконичный и выразительный, а главное быстрорастущий язык. Вполне вероятно, что в недалеком будущем сможет составить конкуренция C++.
evseev
08.07.2016 14:07Какой С, какой ASM? Паскаль? Первый язык должен быть с низким порогом входа, писать на нем должно быть просто и по возможности язык должен быть современным и востребованным, а так же кроссплатформенным.
На С хорошо работать с железом, но сколько вообще людей это делает? ASM? А для чего именно ASM? Для каких процессоров? Для х86 и DSP он различает как небо и земля. И главное зачем? Паскаль? Что вам начинающие сделали? Куда вы потом с ним?
В качестве первого языка я считаю практически идеальным Python. Начать писать на нем очень просто, учится можно на чем угодно включая телефоны, позволяет писать все от простых программок и автоматизирующих скриптов до мега проектов. Можно писать в любом стиле. От скриптов до функционального программирования. Остается добавить, что для Python есть такая IDE как PyCharm. Когда ты мало понимаешь что происходит даже выловить опечатки уже большое дело.
А уже потом станет понятно что именно хочется делать. И учить нужно будет то, что интересует, а не то, что учил кто-то. И учил замечу не потому, что в этом был хоть какой-то смысл, а потому, что так получилось.
PS: я понимаю, что кто-то советует начинать с функциональных языков. Например за это ратует Кнут. Но он преподаватель и рассматривает процесс с точки зрения первоначального обучения студентов.Scf
08.07.2016 15:04В 90е в хороших школах на информатике детям давали два языка — сначала бейсик, потом паскаль. Сейчас, имхо, питон прочно занимает нишу бейсика. Но если ограничиваться только питоном, то на выходе получаются чистые прикладники. И мы видем тонны ужасных библиотек на питоне, статьи "питон как крутой язык для data science" и программистов, не знающих шестнадцатеричные системы счисления.
Имхо, хорошим стартом является питон (5-8 класс) + С (9-11). Паскаль хоть и по-прежнему хорош для обучения базовым алгоритмам и структурам данных, но очень уж устарел как язык.
MacIn
08.07.2016 15:32но очень уж устарел как язык.
По большей части это вкусовщина. Серьезно — если мы говорим не о сложных проектах, а обучении, то все сводится к «а мне не нравится объявлять переменные в самом начале» или «не люблю блоки с begin/end, хочу фигурные скобки, я так привык».
arielf
08.07.2016 19:05Python и Java, увы, бичи современного научного программирования, учёные, мало понимающие в программной инженерии написали на них много полезных, но ужасно работающих программ.
MacIn
08.07.2016 15:30В школе изучал Basic. В ВУЗе давали стандартно: Паскаль (предмет «Алгоритмизация и структурное программирование»), потом Си в рамках него же, потом ООП на основе Паскаля. Затем Ассемблер, ООП на основе С++ с углубление в шаблоны и прочую перегрузку, потом нестандартное — Лисп, Пролог, параллельно — Организация ЭВМ, от самого железа и до уровня машинных кодов.
По-моему, очень правильная линейка: сначала человек учится что-то конкретное делать (Паскаль), затем изучает более глубоко (Си). То же с Ассемблером — сначала программируем в мнемокоде, а потом уже в машинной и изучаем «электронную» часть. И с ООП — сначала простое — на основе Паскаля, потом углубление. Потуги идти всегда от простого к сложному приводят к тому, что обучение идет от тяжелого к легкому и вся охота отбивается еще на раннем этапе.
Сейчас вместо Паскаля ввели Java, заместив 2 курса (программирование на ЯВУ и ООП).
gdredmoon
08.07.2016 16:20Сперва лучше выучить Python потом ассемблер и уже дальше Cи и подобные языки. сам так учил. Питон проще понять для человека который не сталкивался с программированием, язык то не компилируемый хотя и медленный но для обучения самый лучший, написал код и тут же выполнил его, удобно наглядно, да и ООП проще на нем понять. Си после Питона учится легко да и сам язык тоже простой, легкий и программы на нем выходят небольшими по «весу» так что однозначно Python и Си знать обязательно нужно.
punkkk
08.07.2016 19:06+1Читаю комментарии и становится страшно за свое будущее, в глаза не видел паскаля и VB, которые рьяно рекомендуют к изучению в первых рядах. Начинал изучение с C# и за года пол написал примитивные крестики-нолики. Изучал, правда, на специальных курсах и мы использовали visual, расставляли формочки и прочее. Сейчас, спустя много лет, до сих пор не сталкивался с чем-то непонятным в плане изучения, восприятия в программировании. Изучать надо с того, что показывает сразу результат (для меня было невообразимо, что можно так легко делать приложения под Win), а не в консоли текст наблюдать.
p.s.
Ничего против консоли не имею — обожаю.MacIn
08.07.2016 19:44Читаю комментарии и становится страшно за свое будущее, в глаза не видел паскаля и VB
Дата рождения:
17 января 1994
Логично. Время, внезапно, идет, популярные технологии сменяются.
Изучать надо с того, что показывает сразу результат
Паскаль с упомянутым вами VB и в совсем древнем варианте, Бейсиком (Питоном сегодня) — и есть то, что «дает результат сразу», по сравнению с Си, например.Dum_spiro_spero
10.07.2016 20:28Я освоил Бейсик и Фортран по книжке — благо в школе были компьютеры — и пару раз что-то объяснил преподаватель информатики, дальше было понятно всё. Си — вечером за чашкой чая друг объяснил/написал основные операторы и дальше была классическая книга K&R. Ради ASM пошел на курсы.
Зачем нужен Паскаль? Я так понимаю, что преподаватели учат тому, чему учили их — вот нынешние студенты и страдают. На примере нашей лаборатории — все студенты которые появлялись моментально переходили на Си и о Паскале/Делфи больше никогда не вспоминали.
На Паскале тоже пришлось что-то написать — переделывал чужую программу.
punkkk — вот-вот — без VB и P можно неплохо жить.
DrPass
10.07.2016 20:45Паскаль лучше С годится для обучения, это уже много раз проходили. Зачем нужна Delphi? Ну, сейчас её актуальность уже прошла, ИМХО. Но в годы своей «молодости» это был идеальный инструмент для создания Windows-приложений, и по производительности Delphi-программистам просто не было равных (ну, кроме VB-программистов, которые были сильно ограничены своей платформой).
DistortNeo
10.07.2016 21:38Паскаль нужен, чтобы не тратить время на Бейсик. Т.е. идти по цепочке Паскаль -> C -> ASM -> языки высокого уровня.
А вот Delphi для обучения программированию не нужен. Он действительно был актуален 10-15 лет назад, но не за счёт языковых возможностей, а из-за библиотек. Сейчас для тех же целей гораздо актуальнее изучать C#/Java.
eydemidov
08.07.2016 20:45Я первый раз что-то написал в школе на бейсике, на дополнительном занятии по информатике, первым заданием было что-нибудь нарисовать на экране с его помощью. На компах был DOS и соответствующий редактор.
Это было довольно неплохо. Для школьников, по-моему, разницы не много.
Хотя конечно, чем «круче» выглядит результат, тем лучше.
samo-delkin
09.07.2016 06:16Одно только не понял: что ты написал в итоге и на чём?
Я пользуюсь своими программами каждый день на протяжении лет. Дорабатываю их точно так же, периодически выделяя по несколько недель, чтобы не отвлекать мозги.
И мой путь был C -> Python -> Asm с самого начала, исходя только из практических задач. На рынок и рейтинг TIOBE мне абсолютно наплевать. Для меня важно взять хороший инструмент и сделать с его помощью то, что надо для работы.
Почему мне нравится C — потому что на нём очень коротко можно записать.
Почему мне нравится Python — потому что на нём очень быстро можно записать.
Asm — инструмент для ковыряния в уже готовых программах (когда нужно вклинить своё что-то).
0xd34df00d
10.07.2016 01:00Грустно очень, когда плохая книга отбивает любовь к языку, в результате получаются совершенно необъективные и хейтерские абзацы про C++. И в комментариях тоже, да.
Пишу в основном на C++ и Haskell. Мои два самых любимых языка. Зачем в добром разуме писать на С что-то, отличное от ядер ОС и прочего подобного, представляю плохо.
DmitrySpb79
10.07.2016 12:50Статья конечно спорная (изучение Objective-C и Smalltalk чего стоит, особенно учитывая что сама Apple «переводит» всех на Swift, ну да ладно, это личные вкусы автора, о которых не спорят).
Если по теме в целом, то язык для изучения программирования должен обладать следующими свойствами:
— Простота освоения. Язык должен иметь минимум лишнего синтаксического «мусора» ([привет ObjectiveС:[с его нагромождениями скобок]]), не требовать монструозных дорогих IDE на целый DVD-диск (привет Visual Studio). Отличная среда в этом плане кстати, это Arduino IDE, минимум контролов, и ей даже инсталлятор не нужен.
— Язык должен иметь реальную практическую применимость (поэтому Borland Pascacal тоже идет лесом вместе с древними симуляторами DosBox, так же как и «мертвые» языки типа Smalltalk-a). Суть в том, что ученик долженпочувствовать в себе силуиметь возможность сделать для себя (и показать друзьям, родственникам и пр) какую-то реально полезную программку (неважно что, качалка файлов, скрипт для домашней странички, или установщик плагинов для Майнкрафта). Т.е. нужен полезный «выхлоп» и разбор _прикладных_ задач, чтобы был интерес в первую очередь. Нет ничего скучнее того, когда ученик понимает что проходимое на уроке ему никогда не пригодится. Из этого следует следующие 2 пункта.
— Нужно с учениками писать код на _разные_ платформы. Ученик должен попробовать и виндовую программу из форм «сбацать», и консольное приложение написать, и светодиодом на контроллере помигать, и на смартфоне приложение запустить.
— Нужно разбирать практические задачи: работа с файлами, сетью, ввод-вывод и пр (а для этого язык должен быть простым и высокоуровневым). Теорию типа «какого размера бывают переменные» и «куда растет стек» можно рассматривать параллельно во время решения прикладной задачи.
В итоге, что остается? Наверное, «С с классами» для начала (отказываться от string например, ради pure C все же нецелесообразно), параллельно Python как скриптовый язык, параллельно что-то типа Visual Basic чтобы делать простые приложения под Windows.
А еще хорошо бы, чтоб зарплата учителя информатики в школе примерно соответствовала зарплате программиста. Тогда туда пойдут те, кто реально умеет и любит это делать, а не выпускники пед.вузов, обучавшиеся по программам 20-летней давности.punkkk
11.07.2016 13:55Мало того, так еще информатика то не программированию учит. Ну, у нас учила вообще непонятно чему. Доходило до того, что меня учитель просил помочь с нерабочим ПК, а я всегда иду из глубины, поэтому решил глянуть на месте ли кабель питания… Ну и он оказался вне входа БП. Такая вот информатика.
khim
11.07.2016 15:26Невоткнутый шнур питания — это классика. Я как-то столкнулся с обратным: когда два кабеля — хуже чем один. Если подключить принтер к компьютеру сразу двумя кабелями (USB и LPT), то он не работает. Хотя казалось бы… впрочем это, наверняка от принтера и драйверов зависит…
chaetal
10.07.2016 22:00+2Однозначный + в карму за статью. Поставил бы второй за попытку объяснить продвинутым современным программистам зачем нужен «мертвый» Smalltalk — но нельзя. Да и результат как-то не добавляет оптимизма по поводу нашего будущего…
Существует мнение, что Smalltalk вообще первым языком должен быть… Интересно, существуют ли примеры?arielf
10.07.2016 22:22Спасибо!
chaetal
11.07.2016 08:47Вчера как-то забыл написать замечание о том, что совсем не упоминается Pharo. А между тем, это один из ведущих «диалектов» Smalltalk-а. Пожалуй, возьму на себя смелость заявить, что уже наиболее продвинутый и наиболее перспективный как с точки зрения использования для «коммерческого», так и для «научного» использования.
w1ld
14.07.2016 11:52Немало людей посещают подобные курсы (за приличные деньги), учатся писать screensaver, радостно публикуют его в Сети и получает на выходе красивый сертификат с которым бегут устраиваться в фирмы.
Конечно, если нужно стать настоящим программистом, то стоит такой путь выбрать: авторитетные книги, стандарт, пробовать алгоритмы реализовавывать и др. А те разрекламированные курсы, легкие книги и т.п., видимо, подходят для знакомства, вовлечения не связанных с программированием людей. Такие упрощенные версии позволяют хоть как-то прикоснуться к программированию. Тем оно становиться понятнее. Действительно, стоит понимать зачем идешь на такой курс или зачем читаюшь такие книги. Ведь, такой дилетант выглядил бы смешно, если бы ему нужно было бы сделать screensaver, а он пошел бы Кормена читать. И наоборот, как у вас.VolCh
14.07.2016 14:38Очень часто такие курсы себя позиционируют именно как полную подготовку к профессиональной деятельности программиста с нуля, а не «хотите прикоснуться к программированию?»
robert_ayrapetyan
Важно не упустить «введение» (биты, байты, слова, системы счисления и т.п.). Тут как нельзя кстати подходит ассемблер (у вас он почему-то оказался в середине), а уже после него можно плавно и вдумчиво переходить на С.
Symphel
Ну для того, чтобы разобраться в «битах, байтах, словах, системах счисления» ассемблер в общем-то необязателен. Он как раз выступит естественным продолжением после С, углубляя знания студента. Но начинать с C я бы не стал.
Зачем учить мертвые языки вроде Smalltalk и Ada мне вообще непонятно.
arielf
Symphel
Написали, но живее они от этого не становятся. Почти нет сообщества, на stackoverflow ответов, я думаю, не найти, применить особо негде, скорость изучения из-за этого будет ниже. И что потом с этими знаниями делать? Для общего развития? Для изучения обширной темы «какими разными бывают языки программирования» не имеет смысла прыгать по всем языкам какие есть, лучше глубоко изучить два-три языка, реализующих различные парадигмы и теоретическую часть.
Кстати, а сколько времени вы отводите на изучение 8 (!) языков программирования? Отмечу, что среди них нет большинства самых востребованных из КДПВ — Java, C#, PHP, Python. Их потом дополнительно учить?
arielf
Вы думали или проверяли? Smalltalk on stackoverflow.com Ну и проверьте списки рассылки Squeak.
khim
Там ещё и 500 ответом про brainfuck есть. И на логарифмической шкале, увы, Smalltalk всё-таки ближе к Brainfuck'у, чем к какому-нибудь pythonу. А если есть желание покопаться в истории — то можно и на BCPL и на Cobol взглянуть, зачем Smalltalk'ом-то ограничиваться?
hdfan2
Кстати, учить Кобол хоть, наверно, и скучно, зато прибыльно. Софта на нём написано немерянно, и его нужно сопровождать/расширять, а знающих этот ЯП всё меньше и меньше.
veloriba
Это как латынь. Никто не говорит, но все лингвисты учат:)
3fed
Ну что вы, латынь же учат далеко не только лингвисты же и даже как-то используют.
khim
Ну если вы собираетесь разработывать новый язык, то посмотреть на Smalltalk может быть полезно. Но если вы хотите что-то такое запрограммировать — то вряд ли…
arielf
Но позвольте — http://www.cincomsmalltalk.com/main/successes, причём это не legacy, а новые программы, запущенные менее 10 лет назад.
fetis26
На латыни говорят врачи и биологи
RolexStrider
Биты, байты, слова, системы счисления, арифметика указателей — всё это и есть C. А вот ИМХО после — если еще останется желание залезть глубже в кроличью нору — asm.
xPomaHx
Во введении имхо более важно понимать как работает парсер. Что такое блок ворожение оператор и тд. У меня товарищ у себя в городе делал интернет магазины на заказ, я ему минут 30 объяснял что доллар в jquery это просто функция.
tsabir
Минуту убил, чтобы понять при чем тут «ворожение»…