All streams
Search
Write a publication
Pull to refresh
33
0
Огромный Боевой Человекоподобный Робот @Tanner

Python-программист

Send message
Я не понимаю, откуда вы взяли эту «одну строчку». Я нигде ничего не говорю об объёме примеров. Я сравниваю языки по количеству и сложности тех концепций, с которыми студенту приходится столкнуться в анализе даже самой простой программы на данном языке.

Стиль обучения типа «сейчас напишите так, а в следующем семестре узнаем, зачем» я не считаю допустимым. А объяснить работу программы на Basic, ничего не откладывая «на потом» и не прикрывая ладошкой, намного проще, чем, скажем, работу эквивалентной программы на Java. Поэтому Basic лучше подходит для обучения программированию, чем Java.

Аргументы в духе «дальше применить» я не принимаю, потому что я говорю об обучении программированию, а не о практике. Лучше быстро и легко научиться программировать на бесполезном языке, а потом выучить востребованный на практике язык и пользоваться им, чем выбрать для обучения программированию слишком сложный язык и биться лбом об стену.
Был пост о Java именно как о первом языке программирования, я продолжил тему обучения программированию. Вы и PaulZi говорите уже о практике программирования, это − другая тема.
Это вы говорите про простоту реализации языка, а я говорю о количестве и сложности базовых понятий программирования, с которыми приходится столкнуться в анализе даже самой простой программы на данном языке.

Дополнил про Brainfuck тащемта.
Нет уж, first things first. Я хочу так знакомиться с чудесным миром программирования, чтобы простое приложение было действительно простым, а не как на Java. А когда дойдём до сложных, то там и решим, что делать: внимание тренировать, best practices внедрять, или вообще ЯП менять.
Неважно, какую именно концепцию из базового набора вы хотите продемонстрировать − вывод текстового сообщения, или арифметику, или циклы. Важно, что одни языки программирования позволяют это сделать лучше, чем другие. Об этом и статья.
Моя основная мысль − человеку трудно выучить более одной концепции за раз, поэтому лучше учить программированию на примере языков, фичи которых легко изолировать друг от друга и показать по отдельности.

А вы хотите сразу вывалить студенту на голову все концепции языка, все фичи, да ещё библиотеками-фреймворками всё сдобрить, графика там, UX, RDBMS… Это что, такой особый вид дедовщины? Или просто саботаж учебного процесса? ;)
Я могу плавать в терминах, но раз официальное название этой штуки − scope resolution operator, то надо думать, что она имеет отношение к scopes (областям видимости).
Я бы тоже усомнился в профессионализме, если бы посмотрел, как финансируются и управляются ВУЗы в России, как эмигрируют учёные, преподаватели и т. д. Языки программирования к этому не имеют отношения.
единственный косяк, который ломает мозг новичкам

А как же маниакальная страсть к именованию неймспейсов, так что необходимо объявлять класс в самом первом хеловорлде? «Сначала запомните этот бойлерплейт, про классы узнаете как-нибудь потом» − это просто краеугольный камень в обучении Java как первому ЯП. Мне кажется, трудно придумать что-то более мозголомное.

А как насчёт отсутствия беззнаковых целых? Знаковый byte разве мозг не ломает?
Если ваш ЯП имеет гибкие, расширяемые, легко сериализуемые структуры данных, то вы просто пользуетесь ими. Но если система типов вашего ЯП такова, что проще описать структуру данных на чём угодно другом, то a cat is fine too почему бы и не на XML?
Github − это же не энциклопедия. Подпишитесь на рассылку linux-sunxi, там знают.
А есть какие-то предположения, почему так дорого?
Ну, значит, надо что-то где-то допилить, чтоб пользователи предпочитали всё что нужно бесплатно установить сами вместо того, чтобы платить условному Амазону. Раз платят, значит пока установка чего-то, что Амазон уже установил, вызывает боль.

Да почему обязательно боль? Я сейчас бегло глянул на цены EC2 и Amazon ElasticSearch on-demand: получается, что готовый эластик стоит юзеру дешевле, чем если его ставить самостоятельно. Это нечестная игра, демпинг. Elastic Inc ничего не может этому противопоставить в техническом смысле.

исходники от первоначального продукта доступны, значит должно быть не сложнее, а проще поддержать «инновации» в API.

Вопрос опять же не в том, что проще, а зачем вообще. Зачем разработчику популярного продукта, наверняка имеющему планы по его развитию, отвлекать ресурсы от этих планов и тратить их на копирование фич своего же закрытого клона?
И мне в личку, пожалуйста, если нетрудно.
Понятно же, что речь только про ES

Если речь про сферический ES в вакууме, то он и устанавливается одной командой, наверное. ;)

На самом деле юзабилити продукта как таковое тут не при чём. У условного Amazon как у облачного провайдера есть очевидное преимущество перед условным Elastic или условным Canonical: он имеет возможность устанавливать что угодно на сдаваемый им в аренду компьютер, а Elastic или Canonical вынуждены полагаться на арендатора. Я думаю, это преимущество вполне может считаться неконкурентным.

Ах он злой, можно подумать что майкрософт делится кодом с разработчиками вайна.

Это не очень подходящая аналогия: wine не является первой реализацией win32, и MS не основывал Windows на общественно доступном коде (по крайней мере, целиком).
Возможно, помогла бы, но вот MongoDB говорит, что может и не помочь. Или у условного Elastic есть другие причины сохранять пермиссивную лицензию. Я думаю, что это уже вопрос второстепенный. Пусть лучше будет пермиссивная и коммерческая лицензии, чем закрытый код.
Сделайте, чтоб действительно всё устанавливалось одной командой и после этого работало как часы, будет другой разговор.

Чтобы три разных профессиональных продукта устанавливались и настраивались одной командой? Серьёзно?

Что мешает поддержать те же изменения в бесплатном продукте, чтоб совместимость восстановилась?

Прежде всего то, что условный Amazon не делится своим кодом с сообществом, в отличие от условного Elastic.

Information

Rating
Does not participate
Date of birth
Registered
Activity