Быдлокодеры
http://linux.org.ru поможет.
Очевидно,
Отдельные быдлокодеры очень старательно маскируются... Но истинный быдлокодерский взгляд и выражение лица выдают их с поличным =)
Примеры кода в студию!
Вряд ли быдлокодер может определяться по коду, скорее по отношению к этому коду и к задачам, которые он пытается решить. Более-менее формализованной теории быдлокодеров я не видел, но иногда встречаются особи, которых слово "быдлокодер" очень удачно характеризует.
Быдло - это такое говно, которое не способно переучиваться, которое держится за свои дебильные привычки, как дрочила за х#$. Быдло не рассуждает рационально, оно оценивает любую технологию по степени популярности и раскрученности. Быдло не должно жить. Быдло надо истребить.
Если гандон заявляет, что ему достаточно java/xml/xsl, то этого более чем достаточно для того, чтобы записать его в быдло, в отбросы.
(с)Анонимус с ЛОРа
А которые только и делают, что переучиваются (MS и прочие часто ведь новые шняги придумывают это кто?
Настоящий программист может писать на фортране на любом языке.
5 раз менял основную платформу кодирования: basic -> asm(z80) -> bp+asm(x86) -> дельфи -> VC++ -> .Net, ни разу не переучивался.
что я делаю не так?
программирование от набора инструментов не зависит, правильно подобранные инструменты лишь позволяют существенно сократить затраты на программирование.
Учти, это не мои слова, спроси значение сих фраз на http://linux.org.ru
А что это ты сразу на свой счёт вопрос принял, а?
мне не нравится, когда утверждается, что можно хорошо жить - ничего не меняя.
а где ты увидел такое утверждение?
в построении твоей фразы - я увидел намек на это утверждение
очень правильные слова про независимоть от языков.
подписываюсь.
> что я делаю не так?
Ты каждый раз менял языка на похожий, поэтому учить мало приходилось. Вот если бы сделал переход например VC++ -> (Common Lisp, FORTH, Haskell, Prolog) — я думаю, учить пришлось бы гораздо больше, и это уже можно назвать переучиванием, т.к. некоторые многие старые методы не работать не будут.
эти языки лишь более выпячивают какие-то отдельные аспекты:
лисп - работа со списками, построение своего прикладного языка
форт - работа со стеком, построение своего прикладного языка
haskell - фяшность,
пролог - декларативность.
да, эти языки за счет выпячивания этого отдельного аспекта - позволяют лучше изучить и понять особенности работы и использования таких аспектов, но само программирование от этого не меняется, т.к. все теми же остаются цели, задачи, проблемы и даже средства.
+1
что такого особенного делают вышеприведенные языки, что не делают языки из приведенной мной линейки?В случае с Common Lisp это макросы, мультиметоды, функции как объекты первого класса и еще много чего. В твоем случае правильнее было задать вопрос, что умеют выученные тобой языки, что не умеет CL...
от этого программа сразу начинает в два раза лучше работать?
это вышеперечисленное - какие реальные задачи помогает решить?
а как-же парадигма языка программирования?
> В случае с Common Lisp это макросы, мультиметоды, функции как объекты первого класса и еще много чего.А в С++, накой нужны классы, перегрузки, виртуальные функции. От них программа в два раза лучше работать начинает? Какие реальные задачи это помогает решить? Ассемблера достаточно, на крайняк С.
от этого программа сразу начинает в два раза лучше работать?
это вышеперечисленное - какие реальные задачи помогает решить?
Ага, так они знают, что такое парадигма! Вот, что-то начинает проясняться по теме...
перегрузка методов нужна для поддержки принципа "одиннаковое - одиннаковое. разное - разное".
перегрузка операторов нужна в редких задачах (в основном в расчетных) при формирование типов похожих на встроенные.
виртуальные функции не особо нужны, но нужны интерфейсы
lisp так же предлагает набор абстракций, только других
классы не особо нужны, нужен оператор точка, т.е. возможность быстро увидеть, что с данной фенькой мы умеем делать.Забавно, а как же куча программистов успешно программирует:
а) без IDE, которая выводит список методов после точки;
б) на динамически типизированных языках?
Может не так оно и надо на самом деле?
этот аргумент что-то доказывает?
еще большая куча людей вообще успешно решала/решает свои задачи без компьютера...
Я утверждаю, что польза от вот этой вылезающей подсказки со списком методов минимальна; значительно меньше, чем о ней говорят.
а то ведь бывает победа и Пиррова...
Согласен, поэтому и пишу частенько в последнее время на Ruby/Python - значительно быстрее и дешевле получается, чем на C# или Java, несмотря на отсутствие всяких подсказок.
например, то же самое winapi требует уже намного большего копания в документации, чтобы понять, а что можно сделать, а что нельзя.
код пишешь единолично, или в команде?
А, ну, тогда, пожалуй, я тебя сперва неправильно интерпретировал.
В команде, но небольшой. Однако в ходе работы приходится смотреть и использовать много чужого кода, написанного до меня. И с этим никаких проблем нет.
Ага, так они знают, что такое парадигма! Вот, что-то начинает проясняться по теме...это был контрольный вброс.
"Bydlo-Coder...Advanced Techniques and Strategies"
да, эти языки за счет выпячивания этого отдельного аспекта - позволяют лучше изучить и понять особенности работы и использования таких аспектов, но само программирование от этого не меняется, т.к. все теми же остаются цели, задачи, проблемы и даже средства.
Ты ещё вспомни, что всё Тьюринг-инвариантно
Кроме квантовых компьютеров, разумеется
Ассемблера достаточно, на крайняк С.
Неа, ассемблер нужен только склеротикам, которые никак не могут запомнить таблицу машинных кодов и адреса собственных переменных/функций
именно поэтому и предлагаю взять конкретную стандартную задачу - и показать, что, например, наличие макросов, мультиметодов и т.д. - ускоряет разработку на порядок.
> именно поэтому и предлагаю взять конкретную стандартную задачу
стандартная задача для машины тьюринга - это что-то вроде сложения двух чисел?
проблема в том, что единственная идея оптимизации без потерь - это LZW, когда более часто встречающиеся вещи (более стандартные) кодируются меньшим кол-вом бит.
следствие:
под все задачи сразу нельзя разработать мегаудобный язык.
мегаудобный язык можно только разработать под определенный набор стандартных задач.
соответственно, я и прошу привести набор стандартных задач - на которых проявляется мегаудобство от наличия макросов, мультидиспетчеризации и т.д.
что бы решить стандартную задачу, её не надо разрабатывать, её надо закодить
т.е. Линус Торвальдс взял и просто закодил стандартную задачу?
забыдлокодил!
проблема в том, что единственная идея оптимизации без потерь - это LZWХаффмана ещё, как минимум, забыл.
есть еще куча алгоритмов, предполагающих владение словарем.
Ну алгоритм Хаффмана, собственно, для построения словаря и нужен. Я к тому, что идеи, которые при сжатии используются - разные есть.
это все одно и то же, даже RLE - берется некая "стандартность" и именно она кодируется меньшим кол-вом бит.
на мозгоёбе или асме, чем не Си.
Ведь единственная идея оптимизации без потерь - это LZW....
У них есть общее - методы сжатия, но идеи-то всё равно разные.
на процессоре x86 максимально оптимальным образом реализовать то же самое, что делает asm команда ROL или ROR.
Гут. А что-нибудь размером > 100 кб?
для noname-железки (кросскомпилятора с C нет) в сжатые сроки разово реализовать задачу X.
еще раз повторяю - идея одна и та же, "стандартность" мы кодируем меньшим кол-вом бит.
вот реализация этой идеи: определение стандартности и кодирование - уже отличаются.
Тогда так возьмём язык с 4. операциями:
MOV a ,b - к a присваивается b (можеть быть константа)
INC a - увеличить a на 1
DEC a - уменьшить на 1
JZ a - перейти, если a = 0
И второй - с добваленными операциями
ADD a, b - a = a + b
SUB a, b - a = a - b
И что есть задачи, быстрее реализуемые на первом?
Разумеется, среди тех, которые вообще на них решаемы
потому что сначала придется этот самый компилятор C написать, причем сразу оптимизирующий к тому же.
Я к тому что было ни разу не верное утверждение, что для 2х любых
языков есть задача, решаемая на первом быстрее, чем на втором и
наоборот. Так как это аргуметировалось лишь пакованием кода, то
программа может быть любой длины, вот я и прошу пример.
Тогда он может быть короче любого языка на программе любой длины.
Но таких же языков не бывает...
еще раз повторяю - идея одна и та же, "стандартность" мы кодируем меньшим кол-вом бит.Ну это ты сильно загнул... так можно многие идеи "обобщить". Даже при таком обобщении эта идея называется не LZW, уж точно . А не понял я что ты имел в виду, т.к. называть часто повторяемую информацию "стандартностью" - немного неправильно.
У метро висит реклама про "JAVA-битву". Я снчала по глупости подумал, что это про программирование. А оказывается так можно обозвать чемпионат по JAVA-играм. Извращенцы - лучше б уж zx-spectrum-ы достали или первые x86.
если брать цена/качество, то - да.
на кодирование первого языка достаточно было 2 бит, на расширенный уже 3.
в полтора раза больше надо ботать и держать в памяти.
ps
но ты верно подметил направление в котором развиваются языки.
т.е. делается наблюдение, что в реальной жизни нам приходится не только уменьшать/увеличивать на единицу, но и настолько же часто, а может и чаще нам приходится увеличивать/уменьшать сразу намного.
соответственно добавление команд add/sub нам поможет, а если add/sub добавить, а inc/dec убрать, то на ряде задач жизнь еще больше упростится.
lzw - это первое что вспомнил.
> т.к. называть часто повторяемую информацию "стандартностью" - немного неправильно
так вроде один из синонимов слова "стандартный" и есть словосочетание "часто повторяемый".
например, это видно по фразе "стандартный паттерн поведения"
вот это не совсем понял.
Нельзя рассматривать скорость разработки как единственный фактор. Как правило, разработанные программы нужно потом поддерживать, развивать дальше, встраивать новые фичи по желанию заказчика.
Удобство многих языков состоит не в том, что код на них быстрее писать, а в том, что код на них получается более модифицируемым, в него потом легче вносить изменения.
Также могут быть и другие достоинства — например, код на некоторых языках немного сложнее писать, зато обеспечивается отсутствие важных классов ошибок, как следствие — увеличивается надежность.
совершенно верно.
да, есть наблюдение - что для большинства реальных задач - это так, но ...
но ведь это все не бесплатно, есть оверхед на разработку/поддержку этих инструментов, есть оверхед на освоение, есть оверхед на покупку этих инструментов и т.д., и соответственно на отдельных (особенно не mainstream ) задачах, эти оверхеды могут превышать пользу.
соответственно я и привел пример задачи, когда все эти оверхеды не окупятся.
> Удобство многих языков состоит не в том, что код на них быстрее писать, а в том, что код на них получается более модифицируемым, в него потом легче вносить изменения.
это почти одно и тоже - "быстро писать сегодня" vs "быстро писать завтра"
поясни, что ты подразумеваешь под стандартной задачей
Да это пообще пи***ц, сам долго ржал. Это даже не "знание LZW: со словарем"
У метро висит реклама про "JAVA-битву". Я снчала по глупости подумал, что это про программирование. А оказывается так можно обозвать чемпионат по JAVA-играм. Извращенцы - лучше б уж zx-spectrum-ы достали или первые x86.
Ты еще брейнфак вспомни
И что есть задачи, быстрее реализуемые на первом?
Между прочим, C задумывался как "символическая запись ассемблера", который в свою очередь "символическая запись машинных кодов". Все его потомки из-за этого обладают плохой наследственностью. Так какие языки ты имел в виду?
Удобство многих языков состоит не в том, что код на них быстрее писать, а в том, что код на них получается более модифицируемым, в него потом легче вносить изменения.
например
крупные стандартные задачи:
разработать ОС
разработать компилятор
разработать сайт-визитку
разработать сайт-портал
разработать программу, которая решает счетную задачу
разработать программу автоматической обработки данных (что-нибудь типа биллинга)
разработать программу для обработки данных человеком (что-нибудь типа cms, управление тасками и т.д.)
разработать шутер
и т.д.
вспомогательные стандартные задачи:
добавить в язык тип, который ведет себя почти как встроенный (матрица, комплексное число и т.д.)
разработать систему правил для иерархии типов (например, фигура. круг, овал, квадрат и т.д.)
и т.д.
Ты еще брейнфак вспомниУже
Тут бы сделать финт ушами и в подтверждение слов привести задачу, быстрее реализуемую
на мозгоёбе или асме, чем не Си.
Ведь единственная идея оптимизации без потерь - это LZW....
какие же тогда задачи нестандартные?
разработать ОС
Еще вчера она была стандартной.
Вчера -ю было море по колено.
Теперь у квалифицированных программистов считается, что прогать на ассемблере сложно.
Вот так же и тут: еще вчера любой нормальный программер считал разработку ОС стандартной задачей, а сегодня он уже называет ее специфической и хитроумной.
Регресс налицо
Теперь у квалифицированных программистов считается, что прогать на ассемблере сложно.Наверно, речь идёт о разных ассемблерах. Например, ассемблер для Intel 8086 и для Pentium 4 - это всё-таки большая разница.
Кроме того, я думаю, требования к современным программерам гораздо выше. Вряд ли раньше можно было сказать что-нибудь типа: "Что, ты не можешь Media Player написать?! Открой свой любимый Delphi, возьми TMediaPlayer и причеши его там как-нибудь..."
советую различать: сложно - как геморройно, и сложно - как надо думать.
программировать на асме - это "сложно - как геморройно".
А ещё компилировать "C++ --> машинные коды" вручную совсем тяжело стало. Тоже регресс?
А ещё последний раз человек полностью понимал работу современного ЦПУ ~10 лет назад. Деградация вида?
да - вчера, она была стандартной
сегодня - это узкоспециализированная стандартная задача, соответственно, с точки зрения сегодняшнего mainstream-а - это нестандартная задача.
что вы все так серьезно воспринимаете?
А я думал это про массовое избиение программистов на Java!
Оставить комментарий
enochka1145
Кто это? Как распознать? Как избежать?