Так смешно было про представление что кому-то можно, а кому-то нет, и зависит это от демократии и институтов. А так да, соглашусь, что пока совершенно непонятно куда диван вертеть.
Я сначала тоже поржал, а потом понял, что неплохо было бы объяснить человеку, что именно так демократическая страна с работающими институтами разваливает институты и демократию.
Именно. Поэтому нет смысла нагружать неокрепший ум такими штуками как синтаксис и грамматика языка. Важнее научить комбинировать блоки для получения результата. Более того, это поможет выработать навык самому ставить себе задачи, что забустит дальнее развитие.
Да объяснить можно все что угодно. Только понять что-то проще, а что-то сложнее, впрочем я вообще не о том. Паскаль на этапе "мы дошли до указателей" свою функцию выполнил, можно идти дальше.
Не соглашусь. К С хорошо бы иметь подготовку. Он слишком охотно компилирует то, что по хорошему компилировать не стоило бы, не давая нормальной обратной связи новичку в мире программирования. Но после того как в паскале доходим до указателей, пора идти дальше - в С.
То же самое написал в соседнем комментарии. Pascal идеален для первого языка. Понять, что вообще такое этот ваш код и эти ваши типы данных, а потом забыть язык как страшный сон, но остаться на руках с хорошими системными знаниями.
Так в реальной работе мы тоже в основном пазлы собираем, просто кусочков больше, и грани описаны в документации и/или в подсказках IDE. На мой взгляд, быстрый результат очень хорошо помогает завлечь, а это первое что нужно от первого "языка". Другое дело, что тут не нужно долго задерживаться.
Пусть я окажусь в меньшинстве, но по-моему правильный путь должен быть похож на Scratch, Pascal, C. Очень обзорно, буквально пощупать, понять как работают массивы, структуры, функции и указатели. А дальше уже смотреть, что нравится человеку, главное донести акцент, что в итоге большую часть времени человек будет код читать и пытаться в нем разобраться, а не писать.
При этом требования к скорости разработки обычно исключают возможность освоения чего-то, что никак не пересекается с навыками кандидата. Впрочем, разумеется, зависит от позиции. Наверное, до мидла включительно, вы более правы.
Ну кажется и да, и всё-таки нет. Если этот навык прилагается к другим, актуальным, то это не просто плюс, это вау. А если этот навык единственный, то ну... Как-то такое себе.
Всё так, ты берешь на себя ответственность, что всё взлетит, если это вообще может взлететь. Но сроки, само собой, имеют право стать более резиновыми (кстати, в обе стороны, т.к. чаще всего оказывается, что для достижения цели нужно намного меньше работы, чем было бы по ТЗ).
На мой взгляд немного не так. Чётко поставленная задача зачастую требует действительно колоссальных усилий и траты времени. Мне лично больше импонирует формат, в котором ставящий задачу объясняет цель и предлагает идеи для её декомпозиции, а исполнитель имеет пространство для конечных решений и возможности для диалога. Но да, это подходит не в любых условиях и не с любыми людьми.
Да отличная статья, иногда в рамках развлечения нравится выдавить пару тактов в какой-нибудь литкодной задачке, и уверен, что найду применение прочитанному.
В груви это приводит к огромному числу внезапностей и неожиданностей. Например, что будет если положить в HashMap в качестве ключа GString, а искать String?
Исходники протокола недостаточны (а точнее бесполезны). Слать кому нужно что нужно можно и в рамках протокола, даже имея сквозное шифрование, если клиентское приложение подконтрольно. Например, отправлять на другой сервер данные без шифрования) или в рамках зашифрованных сообщений манипулировать размерами пакетов/задержками.
Так смешно было про представление что кому-то можно, а кому-то нет, и зависит это от демократии и институтов. А так да, соглашусь, что пока совершенно непонятно куда диван вертеть.
Я сначала тоже поржал, а потом понял, что неплохо было бы объяснить человеку, что именно так демократическая страна с работающими институтами разваливает институты и демократию.
В целом относительно похоже устроено, отличия в деталях реализации. И этих деталей дофига и больше.
Автор оригинального комментария судя по всему говорит о https://openjdk.org/jeps/361
Мне кажется, не стоит обвинять человека в том, что он не разобрался, не разобравшись.
Именно. Поэтому нет смысла нагружать неокрепший ум такими штуками как синтаксис и грамматика языка. Важнее научить комбинировать блоки для получения результата. Более того, это поможет выработать навык самому ставить себе задачи, что забустит дальнее развитие.
Да объяснить можно все что угодно. Только понять что-то проще, а что-то сложнее, впрочем я вообще не о том. Паскаль на этапе "мы дошли до указателей" свою функцию выполнил, можно идти дальше.
Не соглашусь. К С хорошо бы иметь подготовку. Он слишком охотно компилирует то, что по хорошему компилировать не стоило бы, не давая нормальной обратной связи новичку в мире программирования. Но после того как в паскале доходим до указателей, пора идти дальше - в С.
Удивлен, как много людей солидарны со мной в вопросе Паскаля. Категорически поддерживаю, лучше языка для старта не найти.
То же самое написал в соседнем комментарии. Pascal идеален для первого языка. Понять, что вообще такое этот ваш код и эти ваши типы данных, а потом забыть язык как страшный сон, но остаться на руках с хорошими системными знаниями.
Так в реальной работе мы тоже в основном пазлы собираем, просто кусочков больше, и грани описаны в документации и/или в подсказках IDE. На мой взгляд, быстрый результат очень хорошо помогает завлечь, а это первое что нужно от первого "языка". Другое дело, что тут не нужно долго задерживаться.
Пусть я окажусь в меньшинстве, но по-моему правильный путь должен быть похож на Scratch, Pascal, C. Очень обзорно, буквально пощупать, понять как работают массивы, структуры, функции и указатели. А дальше уже смотреть, что нравится человеку, главное донести акцент, что в итоге большую часть времени человек будет код читать и пытаться в нем разобраться, а не писать.
Одно другому вообще никак не мешает, скорее даже наоборот.
Очень большая куча кала)
При этом требования к скорости разработки обычно исключают возможность освоения чего-то, что никак не пересекается с навыками кандидата. Впрочем, разумеется, зависит от позиции. Наверное, до мидла включительно, вы более правы.
Ну кажется и да, и всё-таки нет. Если этот навык прилагается к другим, актуальным, то это не просто плюс, это вау. А если этот навык единственный, то ну... Как-то такое себе.
По секрету скажу, что есть и следующий уровень, на котором 80% времени человек сам знает, что сейчас ему стоит делать.
Всё так, ты берешь на себя ответственность, что всё взлетит, если это вообще может взлететь. Но сроки, само собой, имеют право стать более резиновыми (кстати, в обе стороны, т.к. чаще всего оказывается, что для достижения цели нужно намного меньше работы, чем было бы по ТЗ).
На мой взгляд немного не так. Чётко поставленная задача зачастую требует действительно колоссальных усилий и траты времени. Мне лично больше импонирует формат, в котором ставящий задачу объясняет цель и предлагает идеи для её декомпозиции, а исполнитель имеет пространство для конечных решений и возможности для диалога. Но да, это подходит не в любых условиях и не с любыми людьми.
Да отличная статья, иногда в рамках развлечения нравится выдавить пару тактов в какой-нибудь литкодной задачке, и уверен, что найду применение прочитанному.
В груви это приводит к огромному числу внезапностей и неожиданностей. Например, что будет если положить в HashMap в качестве ключа GString, а искать String?
В этом смысле явное точно лучше неявного.
Вот это уже достойно.
Исходники протокола недостаточны (а точнее бесполезны). Слать кому нужно что нужно можно и в рамках протокола, даже имея сквозное шифрование, если клиентское приложение подконтрольно. Например, отправлять на другой сервер данные без шифрования) или в рамках зашифрованных сообщений манипулировать размерами пакетов/задержками.