Программирование, т. 5.1.

Он немного не об этом, а о том, что язык программирования излишне нагружен защитой от ошибок пользователя, что мешает последнему эффективно программировать. Тут соотношение удобство/безопасность явно не в пользу удобства (хотя это смотря с какой стороны посмотреть),.

язык сделан для людей, а не для компиляторов. Как это сделано в шарпе, где даже инт нельзя подставить в условие, лол.

чот с голос

 

язык для людей-гуманитариев чтоли?

 

или с каких пор крокодил плюс два делёное на истину равняется компьютерной мышке?

рубиновый язык

почему вдруг статическая типизация это защита от ошибок пользователя?

Не считаю что шарп сильно сложнее чем жс. На сложных проектах может даже наоборот.

Хотя это конечно же не в плюс жс. Но это говорит о том, что язык вполне себе для технарей с яйцами.

Но это говорит о том, что язык вполне себе для технарей с яйцами.

вполе с яйцами

а скорее просто с упорством дебажить проблемные места с неадекватных поведением программы, когда ты не понимаешь у тебя ошибка которую в нормальных языках должен был ещё компилятор отследить и не дать скомпилить, в крайнем случае свалиться в рантайме или ошибка всё-таки в логике

хотя какой компилятор, о чём это я...

Ну вот. У тебя чисто компиляторское мышление. Оно может и хорошо, до поры.

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

думаю, что в языках со статической типизацией из сигнатуры функции видно, что она возвращает.

ну а такие кустарные изыски только подчеркивают, что жс еще та поделка

С чего бы это подделка? Вполне логично что в не строго типизированных языках каждый тип имеет свое булеаново значение. Поэтому его отрицание даст как раз булеан. А отрицание булеана тоже булеан.

Так что все логично и продумано. Можно даже сказать что язык сделан для людей, а не для компиляторов. Как это сделано в шарпе, где даже инт нельзя подставить в условие, лол.

поделка, а не подделка.

вообще если у нормального человека попросили бы сопоставить каждому значению правда или ложь - то он бы нахуй послал бы

вообще любое преобразование должно быть очевидным. более неявное преобразование не должно приводить к потере данных

===

для таких вещей существует строгое сравнение === собственно говоря другим я и не пользуюсь

не очевидное приведение типов это очень удобно, если это освоить, даже вы в своем шарпе хвалите var которого нет в жаве, хоть там и очевидное приведение для компилятора и иде, все равно это шаг в сторону слабой типизированности

0 это ложь, это все знают, все остальное это правда, и все

Ну вот. У тебя чисто компиляторское мышление. Оно может и хорошо, до поры.

я не люблю когда язык (== его компилятор/интерпретатор, похуй что) не относится к ошибкам как к ошибкам

понимаешь?

если я ошибусь, заюзаю не ту переменную и сравню TextBox со string или (как я часто тупил) попробую присвоить label1 = "hui" вместо label1.Text = "hui" - все ваши супер языки для пацанов с яйцами подобное пропустят, это блядь что вообще такое?

ты делаешь хуйню, а язык не пишет тебе в ответ "эй чувак, ты вот тут сделал хуйню!", он превращает это в "фичу"(с) зато потом происходит какой-то пииздец, а хуй поймешь почему

зато ретурны не надо писать, ВАУ

'use strict';

никогда не было тех проблем о которых вы пишите, не знаю как можно быть настолько ограниченным, чтобы считать бОльшую свободу действия недостатком

даже вы в своем шарпе хвалите var которого нет в жаве, хоть там и очевидное приведение для компилятора и иде, все равно это шаг в сторону слабой типизированности

1) в жаве есть var

2) это никак с типизацией не связано, любой прокол сработает сразу же на этапе компиляции (а может и до компиляции), вар просто избавляет от написания дважды типов вроде System.Collections.SuperCollections.UltraList<Action<AbstractFactoryClassFactory>>>

3) в шарпе с 4.0 появился dynamic - определение типа в рантайме вместо этапа компиляции

что впрочем не особо меняет типизацию языка, потому что

var dvapoy = get2poy(); // тут вернётся int

if (dvapoy) // ошибка компиляции

dynamic dvapoy = get2poy(); // тут вернётся int

if (dvapoy)

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

бОльшую свободу действия недостатком

больше свобода действий = больше простора для проблем

да и в чём соственно заключается эта свобода действий?

ты можешь сравнить 11 == "11" ?

ебать его конём, оно одинаково! (хотя на самом деле нихуя не одинаково, потому что разные типы изначально не могут быть одинаковыми)

больше свобода действий = больше простора для проблем

быть рабом языка это так мило

может быть в связи с таким лояльным отношением у новичков жс вызывает диссонанс, но когда они вникают, то мир кажется лучше, а жс кажется даже красивым (не для рабиблядей, конечно)

сравнивать надо только через ===

если ты пишешь такую хуйню, которая выдает непредсказуемые результаты - значит ты пишешь наобум, не разбираясь в языке. и поделом тебе тогда.

Для других случаев есть техники, предотвращающие подобные проблемы.

для таких вещей существует строгое сравнение === собственно говоря другим я и не пользуюсь

не очевидное приведение типов это очень удобно, если это освоить, даже вы в своем шарпе хвалите var которого нет в жаве, хоть там и очевидное приведение для компилятора и иде, все равно это шаг в сторону слабой типизированности

 

0 это ложь, это все знают, все остальное это правда, и все

var в компайл тайме превращается в тип. кроме того в гайдах рекомендуют использовать var только в том случае, когда тип очевиден. var a = new Position(); но не var a = GetPosition();

ну вот я только что привел тебе пример, как сравнение -1 c true возвращает false.

знают все, кто имел с этим дело. так же как знают, что not a nymber - это number

быть рабом языка это так мило

детализируй

сравнивать надо только через ===

а зачем тогда вообще существует == ?

если ты пишешь такую хуйню, которая выдает непредсказуемые результаты - значит ты пишешь наобум, не разбираясь в языке. и поделом тебе тогда.

почему наобум?

я вполне осознанно пишу код

я вот не сравниваю булевы с datetime-ом, не сравниваю строки с цифрами, а если их надо сравнить (не с точки зрения компьютера - более с человеческой) - конвертирую чтобы дать логическое объяснение такого сравнения компьютеру

компьютер в отличии от людей различает что есть 11 - число или строка

потому что у него всегда есть инструкции по этому типу

компьютера должен выполнять свою работу строго по инструкциям и чем более строгие инструкции тем лучше, потому что компьютер (у него нет "человеческого" восприятия информации) не должен заниматься самодеятельность пытаясь сделать из говна конфету числового типа булев

и чем больше человеческих черт с самодеятельностью ему придают - тем хуже, потому что это всё-равно инструкции от людей, а значит помимо языка как такового нужно ещё и знать в каком именно формате ему придали эту человечность и подстраиваться под видение человечности разработчиками языка, чтобы можно было предсказать его поведение

судя по моему опыту пхп - предсказать поведение живого человека выглядит куда более тривиальной задачей чем предсказание поведения этого языка

если ты пишешь такую хуйню, которая выдает непредсказуемые результаты - значит ты пишешь наобум, не разбираясь в языке. и поделом тебе тогда.

Для других случаев есть техники, предотвращающие подобные проблемы.

в идеале код должен был очевиден даже для людей, которые не знают этот язык

если ты пишешь такую хуйню, которая выдает непредсказуемые результаты - значит ты пишешь наобум, не разбираясь в языке. и поделом тебе тогда.

Для других случаев есть техники, предотвращающие подобные проблемы.

в идеале код должен был очевиден даже для людей, которые не знают этот язык

https://code.google.com/p/minecraft-19lines/source/browse/trunk/Program.cs

если ты пишешь такую хуйню, которая выдает непредсказуемые результаты - значит ты пишешь наобум, не разбираясь в языке. и поделом тебе тогда.

Для других случаев есть техники, предотвращающие подобные проблемы.

в идеале код должен был очевиден даже для людей, которые не знают этот язык

Это утопия. Такого никогда не будет, и быть не должно. Даже если речь идет онли о программистах.

если ты пишешь такую хуйню, которая выдает непредсказуемые результаты - значит ты пишешь наобум, не разбираясь в языке. и поделом тебе тогда.

Для других случаев есть техники, предотвращающие подобные проблемы.

в идеале код должен был очевиден даже для людей, которые не знают этот язык

Это утопия. Такого никогда не будет, и быть не должно. Даже если речь идет онли о программистах.

ну почему

вот код на РАБИ вполне понятен

twittergem.create_twitter s_lichnimi_soobsheniyami, krasivi_design