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