objective-c

[Bоpo6eu]

На старости лет решил обучиться программированию на языке objective-c, стоит ли начинать с этого языка?

[crazy-mike]

На старости лет решил обучиться программированию на языке objective-c, стоит ли начинать с этого языка?
Скорее всего не стоит. С таким же успехом можешь заняться PL/1.

[смешно]

начинай с Java.

[crazy-mike]

начинай с Java.
Тоже особого смысла не имеет ( Java FX всё "испортило" :111: ).

[реднек]

На старости лет решил обучиться программированию на языке objective-c, стоит ли начинать с этого языка?

Стоит. Не смотря на угловатый синтаксис, язык обладает неплохой смесью черт взятых от динамических и статических языков. Последний раз, когда смотрел на него, надо было еще с выделениями памяти возится ручками (retain/release), хотя и не настолько много, как в C/C++.
Хотя если совсем начинать, то лучше с Ruby, Python или JavaScript.

[Джентльмен]

а цель какая? развлечение или найти работу? или есть какая то конкретная задача "для себя"? или просто на халяву свалилась книжка с картинками?

[Революционер]

На старости лет решил обучиться программированию на языке objective-c, стоит ли начинать с этого языка?

Лучше начать с этого
http://mitpress.mit.edu/sicp/full-text/book/book.html

[XCNY]

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

[реднек]

Лучше начать с этого
http://mitpress.mit.edu/sicp/full-text/book/book.html

Неплохое начало.

[crazy-mike]

Хотя если совсем начинать, то лучше с Ruby, Python или JavaScript.
Там ещё где-то Go завалялось и Dart :111:

[crazy-mike]

а почему именно етот.. в сша до сих пор и кобол есть и на на нем работаут и зарабативаут
BASIC где-то остался. :111:

[Bоpo6eu]

Стоит. Не смотря на угловатый синтаксис, язык обладает неплохой смесью черт взятых от динамических и статических языков. Последний раз, когда смотрел на него, надо было еще с выделениями памяти возится ручками (retain/release), хотя и не настолько много, как в C/C++.
Хотя если совсем начинать, то лучше с Ruby, Python или JavaScript.
в бурсе учил BASIC

[crazy-mike]

в бурсе учил BASIC
Прикол в том , что этих BASIC-ов существует не менее 20 довольно сильно различающихся между собой версий.
:111:

[Bоpo6eu]

Прикол в том , что этих BASIC-ов существует не менее 20 довольно сильно различающихся между собой версий.
:111:

изучал Visual Basic если быть точным

[crazy-mike]

изучал Visual Basic если быть точным
И хоть где-то он тебе сейчас нужен? :101:

[Bоpo6eu]

И хоть где-то он тебе сейчас нужен? :101:

нет не нужен
но по программе обучения есть значить учи:122:

[crazy-mike]

нет не нужен
но по программе обучения есть значить учи:122:
В суровой реальности ничего кроме C ( даже не С/++ ) особо сильно и не нужно.
Там просто часто на выходе программы должен быть исполняемый сценарий на каком нибудь из shell-ов ( командных языков ) - именно поэтому их и желательно чуть-чуть знать ( чтобы ошибок при генерации сценариев делать меньше).
:310:
На самом деле эти "языки программирования" кроме как на процедурные , функциональные и декларативные ещё и по generations ( поколениям ) умудряются "классифицировать".
Языки , приверженные догме "structured programming" когда-то обозвали "языками третьего поколения". Потом стали модными "языки 4го поколения" - это когда "типа программер" всё делает в "визуальной среде разработки" , а по проекту автоматически генерируется программа на таком языке , которая потом компилируется во что-то "исполнямое" или на "отладочной платформе" или на "платформе реализации".
Кстати - даже для web-applications эти самые "работодатели" хотят не "знания языка программирования JavaScript" ( который каждый год меняется если не чаще ) , а умения работать с jQuery.

Эту "визуальную среду разработки" стали называть IDE ( это не сокращение от idiot - а скорее Integrated Developer(Debug) Environment ).
:310:
Появилось довольно много "программеров" , которые нигде кроме как в IDE работать просто не умеют. А все эти "языки программирования в общепринятом смысле этого выражения" теперь чаще являются языками , на которых "программируют" эти самые IDE-системы. Поэтому знание языков программирования практически нигде не ценится , и за это вообще не платят.
:101:
Adobe Flash - там даже трудно сразу сказать , а что же внути считается "языком программирования" ( их там даже не один - ActionScriot и MXML ). Внутри Java FX - аналогично. А этот Adobe Flash ведь даже пробовали позиционировать в качестве COBOLа для Smart TV!

[Sixteen]

И хоть где-то он тебе сейчас нужен? :101:

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

[Sixteen]

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

[crazy-mike]

представь себе да. я на вб зарабатываю больше сейчас денег
чем за все крутые языки которыми
я пользовался раньше. есть канешно
падробнасти. но если папрастому,
пакалхозному, то я вб
программер. гы гы гы.
Но BASIC ( в варианте VBScript ) как раз "крутой" язык. Даже очень крутой. И в варианте Visual Basic тоже. А из VB for applications вообще DLL-ки можно было грузить ( а делать DLL-ки даже из gcc ).
:310:
И вообще мелькали около четырёх компиляторов с PL/1 для Windows. И где-то есть интерепретатор REGINA REXX , который можно под Windows запускать.
Да и компиляторы с Fortran-а тоже кое-где популярны.

[crazy-mike]

а абджэктив си нислабый ленгвидж. он сложней чем кажэца.
тута уже поминали извращение под названием пиэл-1. или еще
смолток. я б сказал шо лля начинающего программаря он может слишком сложен. но судя по эпплу он практичен.
PL/1 - это совсем не извращение. Вот PL/M - это уже самое настоящее извращение. :111:

[Sixteen]

Но BASIC ( в варианте VBScript ) как раз "крутой" язык. Даже очень крутой. И в варианте Visual Basic тоже. А из VB for applications вообще DLL-ки можно было грузить ( а делать DLL-ки даже из gcc ).
:310:
И вообще мелькали около четырёх компиляторов с PL/1 для Windows. И где-то есть интерепретатор REGINA REXX , который можно под Windows запускать.
Да и компиляторы с Fortran-а тоже кое-где популярны.

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

[crazy-mike]

да виби ваще крутой. и не его втна что большинство его ппограммеров -
абизьяноговнокодеры. это скорей вина микрасофта.
Не только. IDE для Small Talk ведь в IBM делали! :111:
И у IBM был свой BASIC даже на VM/CMS. :310:

[Sixteen]

Не только. IDE для Small Talk ведь в IBM делали! :111:
И у IBM был свой BASIC даже на VM/CMS. :310:

no kakoe otnoshenie IBM imeet k bezmozglomu marketing departmentu mikrosofta?

[реднек]

В суровой реальности ничего кроме C ( даже не С/++ ) особо сильно и не нужно.
Там просто часто на выходе программы должен быть исполняемый сценарий на каком нибудь из shell-ов ( командных языков ) - именно поэтому их и желательно чуть-чуть знать ( чтобы ошибок при генерации сценариев делать меньше).
:310:
На самом деле эти "языки программирования" кроме как на процедурные , функциональные и декларативные ещё и по generations ( поколениям ) умудряются "классифицировать".

А чего ты так скромно пропустил объектно ориентированые языки?
Вот кстати имею 100% мнение что с C начинать не нужно. Тем более с C++. Если не хочется долго и муторно разбираться с вопросами далекими от прикладной задачи. Это нишевые языки, необходимые там где требуется высокая скорость исполнения и привязка к железу.


Языки , приверженные догме "structured programming" когда-то обозвали "языками третьего поколения". Потом стали модными "языки 4го поколения" - это когда "типа программер" всё делает в "визуальной среде разработки" , а по проекту автоматически генерируется программа на таком языке , которая потом компилируется во что-то "исполнямое" или на "отладочной платформе" или на "платформе реализации".

Вообще в индустрии все движется по спирали. Был моден Lisp когда то, сейчас его функциональные языки тоже в моде, т.к. мультиядерные/процессорные системы сейчас повсеместно, и их удобно пользовать при паралельных вычислениях. Но читать их неудобно, хотя дело привычки. Я назвал Ruby/Python/JavaScript потому как там можно пользовать любую парадигму. В случае JavaScript к тому же ничего не надо кроме браузера и любого текстового редактора.


Кстати - даже для web-applications эти самые "работодатели" хотят не "знания языка программирования JavaScript" ( который каждый год меняется если не чаще ) , а умения работать с jQuery.

Сейчас все несколько дальше ушло. В вафоре CofeeScript (обертка над JS с, более удобным синтаксисом чем JS). jQuery пользуется очень часто, но народ переезжает на фрейворки типа backbone.js, ember.js или angularjs. Это если мы говорим о клиентской части. У веб приложений есть еще серверная.

[crazy-mike]

А чего ты так скромно пропустил объектно ориентированые языки?
Вот кстати имею 100% мнение что с C начинать не нужно. Тем более с C++.
Вообще в индустрии все движется по спирали. Был моден Lisp когда то, сейчас его функциональные языки тоже в моде, т.к. мультиядерные/процессорные системы сейчас повсеместно, и их удобно пользовать при паралельных вычислениях. Но читать их неудобно, хотя дело привычки. Я назвал Ruby/Python/JavaScript потому как там можно пользовать любую парадигму. В случае JavaScript к тому же ничего не надо кроме браузера и любого текстового редактора.

ПОчему "пропустил"? Даже PL/1 ведь очень даже сильно "объектно ориентирован" ( там процедуры могли быть компонентами структур - точнее , тип ENTRY. И динамически создавать такую хреновину тоже можно было. А многие варианты INIT в операторе DECLARE были похлеще чем "конструкторы объектов" :111: ). :111:
VBA и прочие BASIC-и - тоже "объектно-...".
:111:
Да и С++ тоже "объектно...".
Просто "объектно-ориентированные языки" ничем особенно не выделяются из языков , поддерживающих структурирование данных.
:116:
Всё же деление на языки с декларативной и процедурной семантикой несколько корректнее чем на ОО- и всё остальное. Хотя "функциональные языки" тоже можно считать и декларативными и процедурными и ОО-...

[crazy-mike]

no kakoe otnoshenie IBM imeet k bezmozglomu marketing departmentu mikrosofta?
IBM нескольно лет назад ( ужас! несколько - это больше 10ти лет назад :111: ) считалась одним из самых крупных "интеграторов" решений на основе Windows NT. Они даже что-то похожее на Visual PL/1 предлагали. :111:

[Yura717]

начни с Python самый простой язык для изучения ..... и области применения у него большие ....
Python поддерживает несколько парадигм программирования, в том числе структурное, объектно-ориентированное, функциональное, императивное и аспектно-ориентированное. Основные архитектурные черты — динамическая типизация, автоматическое управление памятью, полная интроспекция, механизм обработки исключений, поддержка многопоточных вычислений и удобные высокоуровневые структуры данных. Код в Питоне организовывается в функции и классы, которые могут объединяться в модули (которые в свою очередь могут быть объединены в пакеты).
https://www.coursera.org/course/interactivepython
This course is designed to help students with very little or no computing background learn the basics of building simple interactive applications. Our language of choice, Python, is an easy-to learn, high-level computer language that is used in many of the computational courses offered on Coursera. To make learning Python easy, we have developed a new browser-based programming environment that makes developing interactive applications in Python simple. These applications will involve windows whose contents are graphical and respond to buttons, the keyboard and the mouse.

[crazy-mike]

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

Он только внешне "простой". А в суровой реальность глючит похлеще чем Perl. :116:
Если уже совсем точно - нет "простых" языков программирования. Чем он "проще" по внешнему виду тем сложнее там всё с runtime environment, garbage collection и прочими "фишками".

[Yura717]

Mike, ты прекрасно знаешь что написать 1 + 1 в Питоне проще чем на ассемблере ....

[реднек]

Помимо языка еще важны библиотеки, я б сказал может более важны чем сам язык. Берешь Питон или Руби, и там все есть стандартное и везде работающее. Берешь C++ и долго мучаешся с переносом на другую платформу или разруливанием зависимостей. Objective C, я так понимаю не просто вопрос возник поизучать, а по программировать чего нибудь? На Маке? Там дофига либ, и они не плохие.

[Sixteen]

джаваскрыпт! во язычисче!

[crazy-mike]

Mike, ты прекрасно знаешь что написать 1 + 1 в Питоне проще чем на ассемблере ....
Мне кажется , что на ассемблере проще.

# я очень тупое - это as ( GNU assembler )
sub %eax,%eax
inc %eax
inc %eax
ret
:111:

[crazy-mike]

Помимо языка еще важны библиотеки, я б сказал может более важны чем сам язык. Берешь Питон или Руби, и там все есть стандартное и везде работающее. Берешь C++ и долго мучаешся с переносом на другую платформу или разруливанием зависимостей. Objective C, я так понимаю не просто вопрос возник поизучать, а по программировать чего нибудь? На Маке? Там дофига либ, и они не плохие.
поэтому переносят "платформу" , а не "приложение". Linux -> MinGW ( под Windows )

[crazy-mike]

джаваскрыпт! во язычисче!
да уж - получился ночной кошмар какой-то. :111:

var Four = {
x2plus2 :function (z) { if(z=="2+2") return 4; return "not 4"; }
};

:111:

[реднек]

поэтому переносят "платформу" , а не "приложение". Linux -> MinGW ( под Windows )

A обратно? А на что с другими платформами? И кто переносит, конечные пользователи? Нет, они таким не балуются.

[crazy-mike]

A обратно? А на что с другими платформами? И кто переносит, конечные пользователи? Нет, они таким не балуются.
И туда , и обратно. Но этим конечно же не пользователи занимаются , а всякие там "интеграторы-внедрятели" ( гореть им после смерти в адской микроволновке из микропроцессоров AMD! ).

[Sixteen]

vysokobezopastnyj jazyk zhaba - razneset sifilis po vsemu vashemu kamputeru.
paskoku v ego installjaciju vxodit ask tulbar. i makafi sifilis raznositel'.
spasibo tebe orakl.

[crazy-mike]

vysokobezopastnyj jazyk zhaba - razneset sifilis po vsemu vashemu kamputeru.
paskoku v ego installjaciju vxodit ask tulbar. i makafi sifilis raznositel'.
spasibo tebe orakl.
А где-то у Google затерялся язык Go. :111:

[crazy-mike]

На старости лет решил обучиться программированию на языке objective-c, стоит ли начинать с этого языка?
Короче ( пока тебя совсем не зафлудили всякими там tips & tricks ) - придумай свой собственный язык программирования и пиши всё на нём. А в потом просто "компилируй" всё это в "реализацию на целевой платформе". Когда-то давно это называлось "технология PDL" ( Programming Design Language )
:111:

[реднек]

Короче ( пока тебя совсем не зафлудили всякими там tips & tricks ) - придумай свой собственный язык программирования и пиши всё на нём. А в потом просто "компилируй" всё это в "реализацию на целевой платформе". Когда-то давно это называлось "технология PDL" ( Programming Design Language )
:111:

Я сегодня наслушался много про то что будущее за JavaScript. И я даже могу в это поверить. Не совершенный, со странностями, но простой и сильно распостраненный.

[crazy-mike]

Я сегодня наслушался много про то что будущее за JavaScript. И я даже могу в это поверить. Не совершенный, со странностями, но простой и сильно распостраненный.
Одно время считалось , что будущее за PROLOG....:310:

[реднек]

Майк, если отбросить исторические ссылки и аргументировать выбор, то он:
1. Прост
2. Быстр относительно других языков.
3. Поддерживает множество парадигм, выбирай на вкус.
4. Поддерживаем любым современным броузером, т.е. не надо никаких спец. инструменто разработки.
5. У него есть стандарты
6. У него есть очень большая коммьюнити
7. У него есть много библиотек
8. Он используется в hosted environments и standalone, как

Е еще динамика развития. Тот же jQuery, сильно добавил к популарности языка. И тенденция прослеживается четко. Если лет 10 назад язык казался несколько поделочным, то на текущий момент на нем научились писать очень качественный код.

[crazy-mike]

Майк, если отбросить исторические ссылки и аргументировать выбор, то он:
1. Прост

Прост???????????????? :111:
Во-первых , там есть объекты.
Во-вторых они там ещё и instantiated
В-третьих , там "локальные переменные" можно определять в любом блоке.
В-четвёртых { } там является именно "блоком" ( в смысле BEGIN; END; языка PL/1 ), а не в смысле "составного оператора",
В-пятых - там есть try ....catch
В-шестых - свойства екземляра объекта там являются "динамическими". Там можно "во время выполнения" добавлять объекту новое свойство ( в т.ч. и "метод" ).
:308:
И это "просто"? Этот JavaScript ведь "запутаннее" чем все существующие реализации C/++ и Java вместе взятые.
А ведь я даже о DOM interfaces не вспоминал.

P.S. У меня front-end для работы с БД полностью на JavaScript написан - там просто внутри пустого "тела страницы" всё делается на JavaScript по "onload". Поэтому я очень хорошо знаю всю обманчивую простоту JavaScript. :122:
Как шутили на сайте Google Projects - ну и кто здесь думает , что хорошо знает JavaScript??????
:111:
JavaScript начинался как "простой язык". Но даже в самом начале из-за возможности динамического создания свойств объектов он был во многих отношниях "круче" чем LISP.
А сейчас он превратился в монстрообразное чудище. Меня больше всего удивляет - как при этом кто-то ещё умудряется ругать C.

[реднек]

Прост???????????????? :111:
Во-первых , там есть объекты.
Во-вторых они там ещё и instantiated
В-третьих , там "локальные переменные" можно определять в любом блоке.
В-четвёртых { } там является именно "блоком" ( в смысле BEGIN; END; языка PL/1 ), а не в смысле "составного оператора",
В-пятых - там есть try ....catch
В-шестых - свойства екземляра объекта там являются "динамическими". Там можно "во время выполнения" добавлять объекту новое свойство ( в т.ч. и "метод" ).
:308:
И это "просто"? Этот JavaScript ведь "запутаннее" чем все существующие реализации C/++ и Java вместе взятые.
А ведь я даже о DOM interfaces не вспоминал.

P.S. У меня front-end для работы с БД полностью на JavaScript написан - там просто внутри пустого "тела страницы" всё делается на JavaScript по "onload". Поэтому я очень хорошо знаю всю обманчивую простоту JavaScript. :122:
Как шутили на сайте Google Projects - ну и кто здесь думает , что хорошо знает JavaScript??????
:111:
JavaScript начинался как "простой язык". Но даже в самом начале из-за возможности динамического создания свойств объектов он был во многих отношниях "круче" чем LISP.
А сейчас он превратился в монстрообразное чудище. Меня больше всего удивляет - как при этом кто-то ещё умудряется ругать C.

Объекты это плюс языка.
"instantiated" objects –*мне этот термин не встречался. Ты имеешь ввиду что объекты можно инстанциировать? Ну во первых это так почти везде. Во вторых, это не обязательно для JavaScript. Если конечно ты не имел ввиду что то другое.
{} - блок? А можешь пояснить чем это мешает?
try...catch – это плюс. (Не хочешь не пользуй)
динамические свойства объекта -*это плюс (это долгая тема, но как человек писавший на плюсах 11 лет где такого нет, я могу это смело утверждать, возьми хотя бы библиотеки для тестирования кода, там где нет динамики это страшный пейн)
DOM - оставь пока, не надо мешать все в кучу. Мы о языке. Заметь, что почему то ассоциация про DOM, у тебя возникла, а возникла бы она у тебя если б я сказал что будущее за С? Что лишь указывает но гораздо большую применимость JS.

Там конечно есть неприятные вещи, типа правил на что указывает this, но их не много и workarounds известны. Скажем так их несколько. Сравни с C++, где таких мест сотни, целые книги посвящены этому.

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

[crazy-mike]

.... не ограничивает и в написании ужасного кода. Свобода языковых средств идет на пользу тем кто не умеет писать код. А их отсутвие мешает жить тем кто умеет.
Всё проще - там нет средств , которые принудительно мешают делать глупости. "Хороший язык программирования" должен изначально ограничивать свободу делать ошибки по максимуму. Соответственно JavaScript - "плохой язык программирования" , поскольку на нём можно ночью нарисовать то , что потом днём будет очень трудно понять , а как оно вообще работает.
:101:
В "плохих языках программирования" , конечно же , есть своё очарование. Но "хорошими" они от этого не становятся. Мало того - любой "хороший язык программирования" по мере добавления в него новых возможностей становится "плохим". Pascal , сразу поле того как его придумали - был "хорошим языком программирования". А что с ним сделали потом ???????? :310:
Кстати , кроме C++ ведь был и C--. Там "недостатки C" пробовали преодолевать путём удаления "неправильных дополнительных возможностей".

[реднек]

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

Это экзактли то что пытались сделать разработчики C++. Что б не смог сделать то, что б это. Что бы типы правильно приводились. В итоге правила стали такими сложными что их понимают только language lawyers. И все равно реальность подсовывала постоянно случаи, когда эти правила были нафиг не кому не нужны. Например вектор константных ссылок не приводится к вектору константных ссылок на базовые классы. Безопасная логически операция, но противоречит правилам языка. А const антность в интерфейсах? Тот кто хоть раз пробовал сделеать константные интерфейсы, знает что ей начинают заражаться все вокруг, причем даже то что не хотелось бы заражать. Опять же благое намерение - сделать ограничение помогающее программисту не сделать ошибку. И даже не смотря на все правила языка, есть управление внешними ресурсами, памятью, например, где языковые средства предоставляют мало поддержки программисту. Про умнейшие мозги человечства бьющиеся над составлениями конверсий умных указателей один к другому я уже умолчу.
Вобщем мой вывод был такой - ну их к черты эти языки с костылями не позволяющими упасть. Невозможно заранее подстелить солому во всех местах. Нехорошее это дело. Перешел на динамические и не разу еще не пожалел. Разве тормоза иногда достают. Но JS шустрый весьма. Динамический язык + хорошая тестовая фрейворка для unit/integration тестов - все что надо для счастья.

Кстати я тут был на этой неделе на одной конфе посвященой одной из JS фреймфорков. Там было человек 150, наверное. Когда предложили работодателям проанонсировать вакансии, очередь выстроилась человек в 20.

[crazy-mike]

ну их к черты эти языки с костылями не позволяющими упасть.
Да. Лучше всего "защищались" в PL/1 - (NOERROR): AAA: PROC; ON ERROR GOTO AAA; END;
:111:

[Alex_3112]

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

[crazy-mike]

Javascript популярен по той же причине, по которой были популярны бейсик и php - легко написать программу, и язык стерпит многие вольности со стороны программиста. Что дает очень высокую производительность труда в небольших проектах. С другой стороны, когда проекты становятся сложными, и их приходится поддерживать в течение нескольких лет, преимущества оборачиваются недостатками. Большой проект на Javascript превращается в страшное спагетти, в котором не могут разобраться даже его авторы.
Не превращается - если использовать "объекты" в качестве "модулей" и если не пользоваться всякими "странными" вариантами eval.
Но после появления web-worker-ов говорить о том , что на JavaScript "легко писать программу" ??????
А JavaScript "популярен" практически по единственной причине - в браузерах просто ничего другого нет. Если бы IBM сделала браузер с поддержкой PL/1 вместо JavaScript ( или хотя бы REXX )....:111:

[Alex_3112]

Не превращается - если использовать "объекты" в качестве "модулей"
Видел я эти Javascript объекты. По мере загрузки страницы они могут меняться, как облака в весеннем небе.

[Sixteen]

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

nu sie svojstvo ne ekskluzivno dlya imenno dzhavaskripta

[Alex_3112]

nu sie svojstvo ne ekskluzivno dlya imenno dzhavaskripta
Связано это, на мой личный взгляд, с отсутствием строгой типизации.

[crazy-mike]

Видел я эти Javascript объекты. По мере загрузки страницы они могут меняться, как облака в весеннем небе.
Там ещё и сам код может меняться "как облака в весеннем небе" прямо во время выполнения. :111:

[crazy-mike]

Связано это, на мой личный взгляд, с отсутствием строгой типизации.
Со "строгой типизацией" было бы ещё хуже. Примерно как в ( Adobe Flash ) ActionScript. :111:
А представь "объектно ориентированый язык" в котором каждый из объектов extends Object ( является производным от абстрактного класса Object ).... Какая вообще может быть "строгая типизация" в этом случае????? :111:

[Sixteen]

Связано это, на мой личный взгляд, с отсутствием строгой типизации.

have you ever seen a c++ object oriented spaghetti? Or even templatized object oriented spaghetti?

[Alex_3112]

А представь "объектно ориентированый язык" в котором каждый из объектов extends Object ( является производным от абстрактного класса Object )....
Хм, а что в этом такого страшного?

[Sixteen]

Со "строгой типизацией" было бы ещё хуже. Примерно как в ( Adobe Flash ) ActionScript. :111:
А представь "объектно ориентированый язык" в котором каждый из объектов extends Object ( является производным от абстрактного класса Object ).... Какая вообще может быть "строгая типизация" в этом случае????? :111:

morons will object that such a language would have very strong run-time type checks.

[Sixteen]

Хм, а что в этом такого страшного?
this path leads to spaghetti!

[Alex_3112]

have you ever seen a c++ object oriented spaghetti? Or even templatized object oriented spaghetti?
Скажу так - для создания спагетти размер программы на C++ должен быть заметно больше, чем на weak-typed language.
Все это применимо к практическим проектам, если не варить спагетти специально.

[Alex_3112]

this path leads to spaghetti!
But, unlike in weak-typed languages, one has to deliberately create new types.

[crazy-mike]

morons will object that such a language would have very strong run-time type checks.
:111:
freak run-time checks :111:
эти проверки никакого особого смысла не имеют во время выполнения. Разве что только в варианте "генерация кода для работы с отладчиком".

[Sixteen]

Скажу так - для создания спагетти размер программы на C++ должен быть заметно больше, чем на weak-typed language.
Все это применимо к практическим проектам, если не варить спагетти специально.

chem bol'she tipov dannyx naburujut tem strashnej stanovitsa spagetti!

[crazy-mike]

chem bol'she tipov dannyx naburujut tem strashnej stanovitsa spagetti!
Да. А если учесть , что у каждого из этих типов данных свой конструктор есть ( и деструктор ). И эти конструкторы-деструкторы как начнут один другой вызывать....:310:
Супер-спагетти - множественное наследование , например. :101:

[Sixteen]

Да. А если учесть , что у каждого из этих типов данных свой конструктор есть ( и деструктор ). И эти конструкторы-деструкторы как начнут один другой вызывать....:310:
Супер-спагетти - множественное наследование , например. :101:

sobsna naibolee strashnyj spagetti paluchaetsja ot inxeritansa, osobenno ot mnozhestvennogo inxeritansa kotoryj nagruzili virtual'nost'ju v dopolnenie ko vsemu,
a chtoby bylo ves'ma legko i udobno chitat' kod dobavili kuchu templejtov sverxu.
a po seredine vsego etogo zolotoj baxrominkoj budut sverkat' si-kasty.

[Alex_3112]

chem bol'she tipov dannyx naburujut tem strashnej stanovitsa spagetti!
Это да, для любого языка справедливо.

[реднек]

Скажу так - для создания спагетти размер программы на C++ должен быть заметно больше, чем на weak-typed language.
Все это применимо к практическим проектам, если не варить спагетти специально.

Спорный вопрос. Как раз не возможность доопредить объекты/класс в runtime, если авторам классов не была предусмотрена такая возможность, приводит к использованию наследования к месту и не к месту. Раз иерархия классов выстроена, ее очень тяжело потом менять.

[Alex_3112]

Спорный вопрос. Как раз не возможность доопредить объекты/класс в runtime, если авторам классов не была предусмотрена такая возможность, приводит к использованию наследования к месту и не к месту. Раз иерархия классов выстроена, ее очень тяжело потом менять.
А насколько часто нужно доопределять что-то в runtime? Нет, это конечно мощно и круто, но открывает ящик Пандоры.

[crazy-mike]

Спорный вопрос. Как раз не возможность доопредить объекты/класс в runtime, если авторам классов не была предусмотрена такая возможность, приводит к использованию наследования к месту и не к месту. Раз иерархия классов выстроена, ее очень тяжело потом менять.
Я уже немного говорил об одном парадоксе - очень строгая иерархия классов ( когда все классы происходят от Object ) фактически уничтожает типизацию , поскольку допускается приведение от одного типа данных к другому через Object. :310:

[crazy-mike]

А насколько часто нужно доопределять что-то в runtime? Нет, это конечно мощно и круто, но открывает ящик Пандоры.
Что-то меня на воспоминания об AS/400 с OS/400 потянуло - там как раз всё это и ....:116:
Даже "БД задачи" у Microsoft является чем-то похожим на "доопределять что-то в runtime". Динамическая компоновка во время выполнения для объектно-ориентированных - там тоже. Системы с message handling тоже - особенно если внутри сообщения можно передавать reference на любой instance любого объекта.

P.S. Исходя из всего сказанного , автору самого первого поста этой темы лучше начать с sh - по-своему одного из самых "крутых языков программирования".

[реднек]

А насколько часто нужно доопределять что-то в runtime? Нет, это конечно мощно и круто, но открывает ящик Пандоры.

Ну представь ты читаешь окошко или виджет из файла. В статическом языке, тебе надо что б этот виджет был заточен под то, чтобы содержать цепочку декораторов отвечающих за отработку событий, отрисовку и т.д. В динамическом ты добавляешь в этот виджет методы по мере подгрузки. Опять же про ящики пандоры, смотрим на boost preprocessor metaprogramming library, Boost.function и Boost.Any, Boost.MPL, там это тоже можно все (потому как не хватает), только все сложнее в 100 крат.

[реднек]

Я уже немного говорил об одном парадоксе - очень строгая иерархия классов ( когда все классы происходят от Object ) фактически уничтожает типизацию , поскольку допускается приведение от одного типа данных к другому через Object. :310:

Таких фрейворков кстати довольно много было, типизация правда при этом не уничтожается совсем, ведь ты же не сможешь У Object вызывать методы работы с базой, например, если они определены в наследнике Database и не объявлены в Object. Все это наследование от Object попытка обойти типизацию, но т.к. язык это не позволяет сделать нормально, то обход получается очень корявый, со всяким даункастами или их аналогами.

[crazy-mike]

Таких фрейворков кстати довольно много было, типизация правда при этом не уничтожается совсем, ведь ты же не сможешь У Object вызывать методы работы с базой, например, если они определены в наследнике Database и не объявлены в Object. Все это наследование от Object попытка обойти типизацию, но т.к. язык это не позволяет сделать нормально, то обход получается очень корявый, со всяким даункастами или их аналогами.
Вообще-то был ещё вариант тип данных anytype. :116:
Правда тип данных anyobject даже в Java никто не предложил создать. В JavaScript вот можно getter и setter методы для любого "объекта" переопределять. Самое смешное , что ActionScript 3 у Adobe "подпольно" поддерживает "пожелания с точки зрения здравого смысла". Там inheritance довольно сильно "глючит" , а контейнерные классы работают нормально.

[Alex_3112]

В динамическом ты добавляешь в этот виджет методы по мере подгрузки.
И чего в этом хорошего?
При переходе от строгой типизации к динамической, мы теряем возможность статического анализа кода. Если в динамическом коде что-то глючит, "поймать" это можно только в runtime. А runtime, он разный бывает.

[реднек]

И чего в этом хорошего?

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


При переходе от строгой типизации к динамической, мы теряем возможность статического анализа кода. Если в динамическом коде что-то глючит, "поймать" это можно только в runtime. А runtime, он разный бывает.

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

[Sixteen]

molodec rednek, delo govorit.
glavnoe delo shtob dinamika byla prosta i logichna.
a ne slozhna i nevozmozhna dlya ponimaniya.

[Sixteen]

kstati veb brouzer - naiyarchashiy primer dinamicheskogo interfejsa,
gde staticheskimi javljautsja tol'ko pravila postroenija.

[crazy-mike]

kstati veb brouzer - naiyarchashiy primer dinamicheskogo interfejsa,
gde staticheskimi javljautsja tol'ko pravila postroenija.
Даже "правила построения" в этом случае не являются "статическими". :116:
( но правила построения правил являются статическими )

[Sixteen]

Даже "правила построения" в этом случае не являются "статическими". :116:
( но правила построения правил являются статическими )

dyk. potomu on gipertekst i nazyvaetsa!

[crazy-mike]

dyk. potomu on gipertekst i nazyvaetsa!
Даже lynx уже не является только гипертекстом. :116:
Но мы уже отклоняемся от темы. Автор самого 1го поста ведь спрашивал - какой язык программирования ему лучше "изучать". Если он дочитает до этой страницы - то поймёт , что ни в коем случае таким неблагодарным делом как "изучение языков программирования" ему заниматься не нужно. Это просто опасно для психического здоровья ( особенно объектно-ориентированные с поддержкой multiple inheritance и templates ). Вообще-то даже после "тесного знакомства" с языком sh может крыша поехать. - таких шизофреничеки-"простых" средств для организации "параллельных процессов" ведь почти нигде больше нет.

[Alex_3112]

Это проще, меньше заранее надо думать а какие еще кейсы надо поддержать. В статике, нередко появляется новый кейс и упс, происходит понимание что он не вписывается в текущую иерархию, и надо ее перекраивать. А это дорогая операция.
IMHO, если меньше думать заранее, приходится много-много думать потом.


Ну вот посыл, что мы поймаем баги на этапе статиического анализа, это ложный посыл. Т.е. какие то баги ловятся, но их не так много как хотелось бы и все равно надо писать тесты. А если их надо писать, то уже все равно, полезность статического анализа не велика (для поимки багов).
Я не говорю только об анализе автоматическими баголовами. Я говорю и про чисто человеческий анализ.
Например в Java вылезает ошибка, и есть Stack Trace. Я сразу же смотрю класс и метод, где эта ошибка произошла. Работы, условно, на пять минут. Теперь представим, что ни класса, ни метода, где произошла ошибка, в виде исходников нет. Если я - не автор кода, то работа растягивается на целый день.

Разница примерно как между почтовым адресом и directions.

[crazy-mike]

IMHO, если меньше думать заранее, приходится много-много думать потом.

Слишком много думать заранее и рисовать всякие идиотские иерархии классов , которые никто никогда не будет реализовывать - это ведь тоже "извращение".
:116:
В суровой реальности хватает классов со статическими членами - фактически "модулей" в терминах какого нибудь языка Modula-2 или "namespaces" или "packages".

[crazy-mike]

Ну представь ты читаешь окошко или виджет из файла. В статическом языке, тебе надо что б этот виджет был заточен под то, чтобы содержать цепочку декораторов отвечающих за отработку событий, отрисовку и т.д. В динамическом ты добавляешь в этот виджет методы по мере подгрузки. Опять же про ящики пандоры, смотрим на boost preprocessor metaprogramming library, Boost.function и Boost.Any, Boost.MPL, там это тоже можно все (потому как не хватает), только все сложнее в 100 крат.
Не всё так однозначно. Даже в "статическом языке" выделенное может быть реализовано через какое-нибудь addStyle(...) или setStyle(...). - И не нужно вообще никаких "методов" добавлять. Самое смешное , что язык при этом остаётся "статическим". Вообще-то в "статических" языках есть и совсем "варварские" способы реализации "динамичности" - callback functions и т.д.

[Sixteen]

ierarxija - zlo
intefejsy - dobro
nasledovanie - zlo
mnozhestvennoe nasledovanie - zlo v kvadrate
modul'nost' - dobro
komponenty - dobro
singlton - zlo
fabrikaciya - dobro
hardkouding - zlo
configuraciya - dobro
XML - zlo
NDR - dobro

dinamicheskaya zagruzka - dobro
deklaraciya funkcii cherez typedef - zlo

emissiya koda v rantaime - xoroshie namereniya ne shibko umnyx parney

[Sixteen]

Не всё так однозначно. Даже в "статическом языке" выделенное может быть реализовано через какое-нибудь addStyle(...) или setStyle(...). - И не нужно вообще никаких "методов" добавлять. Самое смешное , что язык при этом остаётся "статическим". Вообще-то в "статических" языках есть и совсем "варварские" способы реализации "динамичности" - callback functions и т.д.

malloc - realizaciya dinamichnosti!
global_heap_alloc + mutex - realizaciya peredachi soobweniy mezhdu tredami i processami!

[crazy-mike]

ierarxija - zlo
intefejsy - dobro
nasledovanie - zlo
mnozhestvennoe nasledovanie - zlo v kvadrate
modul'nost' - dobro
komponenty - dobro
singlton - zlo
fabrikaciya - dobro
hardkouding - zlo
configuraciya - dobro
XML - zlo
NDR - dobro

dinamicheskaya zagruzka - dobro
deklaraciya funkcii cherez typedef - zlo

emissiya koda v rantaime - xoroshie namereniya ne shibko umnyx parney
Короче , поток инструкций - самое большое зло. Инструкция должна выполнятся по мере готовности операндов! :130:

[crazy-mike]

malloc - realizaciya dinamichnosti!
global_heap_alloc + mutex - realizaciya peredachi soobweniy mezhdu tredami i processami!
fork() , wait() , kill(). Ничего больше особо сильно и не нужно. :111:
За использование malloc нужно лоботомию делать.

[Sixteen]

Короче , поток инструкций - самое большое зло. Инструкция должна выполнятся по мере готовности операндов! :130:

message bus - zlo!
virtual memory - zlo!
esli programma vlezet v L1 cash - budet real'no bystro rabotat'!

[crazy-mike]

message bus - zlo!
virtual memory - zlo!
esli programma vlezet v L1 cash - budet real'no bystro rabotat'!
А если в системе вообще нет "памяти для данных" а только один очень большой "регистровый файл"? :111:

[Sixteen]

А если в системе вообще нет "памяти для данных" а только один очень большой "регистровый файл"? :111:

kak govoril odin moj znakomyj aviakonstruktor - takoe ne poletit!

ibo dazhe u BK-0010 byla pamjat' dlja dannyx.

[crazy-mike]

kak govoril odin moj znakomyj aviakonstruktor - takoe ne poletit!

ibo dazhe u BK-0010 byla pamjat' dlja dannyx.
Оно и не летало. Это какие-то микроконтроллеры в газопроводах были. Правда там регистровый файл был очень маленький. :116:
Шиза в том , что там все эти объекты там существовали только для компилятора , который генерировал кучу идиотских команд похожих на mov.

[Sixteen]

Оно и не летало. Это какие-то микроконтроллеры в газопроводах были. Правда там регистровый файл был очень маленький. :116:

dyk u nix vmesto memori nechto tipa kak sim kard.
ja ne sovsem ponjal sho takoe registrovyj fajl. mne predstavilos' nechto vrode vindoze mast die (tm) registry.
a u mikrokontrollerov okromja registrov processora vawe pamjati netuti, tak sho oni bystro bystro vertjaca.
pa maaaaalen'koy okruzhnosti

[crazy-mike]

dyk u nix vmesto memori nechto tipa kak sim kard.
ja ne sovsem ponjal sho takoe registrovyj fajl. mne predstavilos' nechto vrode vindoze mast die (tm) registry.
a u mikrokontrollerov okromja registrov processora vawe pamjati netuti, tak sho oni bystro bystro vertjaca.
pa maaaaalen'koy okruzhnosti
там даже команды cmp были не нужны. Просто что-то похожее на "прерывания" возникало на "конкретное условие". Его не нужно было даже проверять - потому что если такое прерывание возникло , то условие как раз и выполнилось.
:111:

[Sixteen]

там даже команды cmp были не нужны. Просто что-то похожее на "прерывания" возникало на "конкретное условие". Его не нужно было даже проверять - потому что если такое прерывание возникло , то условие как раз и выполнилось.
:111:

xachu nauchicca programmirovat' DSP doski
ili eti fegoveny blagodarya kotorym ARM stal takim krutym - FPGA.
taki za nimi buduschee odnako.

[crazy-mike]

xachu nauchicca programmirovat' DSP doski
ili eti fegoveny blagodarya kotorym ARM stal takim krutym - FPGA.
taki za nimi buduschee odnako.
одно время мелькала мысль о том , что "процедурным языкам" уже как бы пора на кладбище. С другой стороны процедурные языки будут существовать до тех пор пока будет использоваться хотя бы одна из компьютерных архитектур , поддерживающая концепцию "поток команд" ( command flow ).
Ну а если из компьютерной архитектуры убрать не только command flow ( вообще ни одного не оставить ) но и data flow ??????? Оставить только event flow , например????????????

[Кот Пушок]

одно время мелькала мысль о том , что "процедурным языкам" уже как бы пора на кладбище. С другой стороны процедурные языки будут существовать до тех пор пока будет использоваться хотя бы одна из компьютерных архитектур , поддерживающая концепцию "поток команд" ( command flow ).
Ну а если из компьютерной архитектуры убрать не только command flow ( вообще ни одного не оставить ) но и data flow ??????? Оставить только event flow , например????????????

Eсли из компьютерной архитектуры убрать не только command flow, но и data flow, oставить только event flow, то останется только event flow.

:230:

[crazy-mike]

Eсли из компьютерной архитектуры убрать не только command flow, но и data flow, oставить только event flow, то останется только event flow.

:230:
Просто последовательность команд из одной команды как-то язык не поворачивается назвать "потоком команд". :116:
А ко всему прочему даже у команды nop есть "семантический смысл" , который не сводится к "ничего не делать".

[Sixteen]

одно время мелькала мысль о том , что "процедурным языкам" уже как бы пора на кладбище. С другой стороны процедурные языки будут существовать до тех пор пока будет использоваться хотя бы одна из компьютерных архитектур , поддерживающая концепцию "поток команд" ( command flow ).
Ну а если из компьютерной архитектуры убрать не только command flow ( вообще ни одного не оставить ) но и data flow ??????? Оставить только event flow , например????????????

dlya etogo panadabica principial'no drugie sistemy vypolneniya. setevye ili prostranstvennye.
tipa kak prostranstvo lajfa v kachestve prostejshej modeli.

[crazy-mike]

dlya etogo panadabica principial'no drugie sistemy vypolneniya. setevye ili prostranstvennye.
tipa kak prostranstvo lajfa v kachestve prostejshej modeli.
"нейронные сети" уже достаточно давно есть. :116:

[Alex_3112]

ierarxija - zlo
intefejsy - dobro

Абстрактные классы - добро или зло?

[Sixteen]

Абстрактные классы - добро или зло?

paskoku abstraktnye klassy eto chast' inxeritansa to oni blizhe k zlu. oni temnaya storona siiiily.
ne smotrya na to chto inogda oni udobny. no imenno oni - perviy shag k spagetti o kotorom my govorili vyshe.

[Sixteen]

"нейронные сети" уже достаточно давно есть. :116:

bol'shie nejronnye seti vypolnenye v vide zheleza?

[crazy-mike]

Абстрактные классы - добро или зло?
Абстрактные классы - это абстрактное зло. :111:
Их можно заменить на "чисто-конкретные" классы с "пустыми" виртуальными методами. И тогда зло станет "конкретным". :111:

[crazy-mike]

bol'shie nejronnye seti vypolnenye v vide zheleza?
такие гробы ещё лет тридцать назад делали ( я уже даже об аналоговых компьютерах не вспоминаю ).
:116:

[Sixteen]

такие гробы ещё лет тридцать назад делали ( я уже даже об аналоговых компьютерах не вспоминаю ).
:116:

nizastal ... a byla li ot nix prakticheskaya pol'za?

[crazy-mike]

nizastal ... a byla li ot nix prakticheskaya pol'za?
в артилерии , кажется , была ( на линкорах ). :111:
Даже точно не знаю - участвовали ли похожие системы в "форматировании" Бейрута.

[Sixteen]

в артилерии , кажется , была ( на линкорах ). :111:
Даже точно не знаю - участвовали ли похожие системы в "форматировании" Бейрута.

слишком узкое применение ...
FPGA!

[crazy-mike]

слишком узкое применение ...
FPGA!
Узкое?????? - они ведь стрельбой "по площадям" управляли! ( и даже по довольно широким площадям )

[реднек]

IMHO, если меньше думать заранее, приходится много-много думать потом.

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




Я не говорю только об анализе автоматическими баголовами. Я говорю и про чисто человеческий анализ.
Например в Java вылезает ошибка, и есть Stack Trace. Я сразу же смотрю класс и метод, где эта ошибка произошла. Работы, условно, на пять минут. Теперь представим, что ни класса, ни метода, где произошла ошибка, в виде исходников нет. Если я - не автор кода, то работа растягивается на целый день.

Разница примерно как между почтовым адресом и directions.

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

[Sixteen]

Узкое?????? - они ведь стрельбой "по площадям" управляли! ( и даже по довольно широким площадям )

по сравнениу с тем шо wас в каждом телефоне сидит фпга ето узкое применение, даааааа

[crazy-mike]

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

И в этом случае как раз забавно то , что даже и навороченная объектно-ориентированная программа не нужна. Хватает просто не очень сложного генератора выполняемого скрипта по каким-нибудь "файлам конфигурации" ( или по БД проекта ).

[crazy-mike]

по сравнениу с тем шо wас в каждом телефоне сидит фпга ето узкое применение, даааааа
Да - но зато как массивно-шикарно эти железяки выглядели по сравнению с телефонами! :111:

[Sixteen]

Да - но зато как массивно-шикарно эти железяки выглядели по сравнению с телефонами! :111:

a segodnya mozhno fire control osushestvlyat' iz telefona!

[crazy-mike]

a segodnya mozhno fire control osushestvlyat' iz telefona!
Да - но желательно , чтобы телефон находился как можно дальше от контролируемого объекта ( желательно в шести тысячах километров ). Эти современные телефоны ведь такие "хрупкие".
:111:

[Sixteen]

Да - но желательно , чтобы телефон находился как можно дальше от контролируемого объекта ( желательно в шести тысячах километров ). Эти современные телефоны ведь такие "хрупкие".
:111:

nejronnaja set' na lampax tozhi znaesh' li ne ochen' ustojchiva k trjaskam i padeniyam.

[crazy-mike]

nejronnaja set' na lampax tozhi znaesh' li ne ochen' ustojchiva k trjaskam i padeniyam.
На лампах эта радость выдерживала взрыв водородной бомбы. :116:

[Alex_3112]

Та же самая песня с динамическими - как будто там нету классов и методов. Тот же стэк, а в нем класс и метод. Только там еще можно в этот стэк влезть, проинспектировать состояние приложения, и если надо поправить баг ручками по ходу дела.
"По ходу дела" - значит в runtime, так? А runtime нужно воспроизвести у себя в среде разработки, верно? Вот мы и приходим к тому, насколько разный бывает runtime, и если он зависит от фазы Луны - это еще не так плохо.

Кстати в динамических языках, как правило, исходники то как раз есть. Это в случае с плюсами нужен стэк трейс, дамп и еще какая то компилер зависимая ерунда, что б восстановить состояние приложения, что делает траблшутинг гораздо более сложным.
В javascript эти исходники как правило в таком состоянии, что если ты даже поймал преступника за руку, ты никогда не уверен, кто же именно был преступником и даже сколько у него было рук. Руки пристегиваются и отстегиваются так же просто, как пишется "Hello World!"

[реднек]

"По ходу дела" - значит в runtime, так? А runtime нужно воспроизвести у себя в среде разработки, верно? Вот мы и приходим к тому, насколько разный бывает runtime, и если он зависит от фазы Луны - это еще не так плохо.

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


В javascript эти исходники как правило в таком состоянии, что если ты даже поймал преступника за руку, ты никогда не уверен, кто же именно был преступником и даже сколько у него было рук. Руки пристегиваются и отстегиваются так же просто, как пишется "Hello World!"
Это уже не язык виноват.

[crazy-mike]

В javascript эти исходники как правило в таком состоянии, что если ты даже поймал преступника за руку, ты никогда не уверен, кто же именно был преступником и даже сколько у него было рук. Руки пристегиваются и отстегиваются так же просто, как пишется "Hello World!"
вспомни в каком состоянии находились исходники на Fortran-77. :111:

[crazy-mike]

Это уже не язык виноват.
Да. Просто ведь смотря что считать "исходником". jQuery , например , в "компактном варианте". :111:

[Alex_3112]

В том то и прелесть что прямо в продакшене, на серваке. Очень часто можно сразу там посмотреть что не так, даже не воссоздавая у себя локально аналогичный сценарий.
Через Remote debugging, я правильно понял?

Это уже не язык виноват.
Не язык, а одна его возможность - возможность динамического конструирования типов.

[реднек]

Через Remote debugging, я правильно понял?

Типа того. Можно ремотно дебагером атачнуться, можно просто из консоли запустить на серваке еще одну копию процесса из под отладчика, и "общаться" только с ней, есть мулечки которые прямо генерят HTML страницу, через которую можно посылать команды находясь в стеке сервака.
[QUOTE=Alex_3112;6117213]

[Alex_3112]

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

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

[реднек]

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

Нет не означает - в случае ее отладки в момент возникновения. Если даже запускать копию процесса под отладчиком, то все равно там та же ос, те же соединеиния с бд, те же ключи и т. д. Ничего не надо компилить ина практике добраться до места ее возникновения гораздо проще.

Корче, если вкратце, то с переходом на динамические языки я стал более счастливым человеком, поэтому для меня спор статические vs динамические однозначно решен

[Alex_3112]

Нет не означает - в случае ее отладки в момент возникновения.
В момент возникновения в продакшене ошибка заносится в лог, а процессы идут дальше, т.е. поезд уже ушел. Иногда в некоторых средах при этом делается дамп (но почти никогда - в продакшене).

Если даже запускать копию процесса под отладчиком, то все равно там та же ос, те же соединеиния с бд, те же ключи и т. д. Ничего не надо компилить ина практике добраться до места ее возникновения гораздо проще.
Это конечно проще, что все происходит на одном и том же сервере. Но на моей практике, это очень большая роскошь, когда программистам позволено лезть дебаггером в продакшн. У нас, например, этого нельзя делать даже в тестовом звене.


Корче, если вкратце, то с переходом на динамические языки я стал более счастливым человеком, поэтому для меня спор статические vs динамические однозначно решен

У меня все в точности наоборот. Если код статичен - я могу нестись, как наскаровская машина по трассе. Если начинается динамика - инъекции, аспекты, рефлексия и т. д. - это все ухабы, и моя скорость падает до скорости трактора.

[Sixteen]

kstati. kak jazyk piton kruche vsex! da! da! da!
piton ochen' krutoy!

[реднек]

В момент возникновения в продакшене ошибка заносится в лог, а процессы идут дальше, т.е. поезд уже ушел. Иногда в некоторых средах при этом делается дамп (но почти никогда - в продакшене).

Это конечно проще, что все происходит на одном и том же сервере. Но на моей практике, это очень большая роскошь, когда программистам позволено лезть дебаггером в продакшн. У нас, например, этого нельзя делать даже в тестовом звене.


Лог то же присутствует само собой. И лог бд, и ошибки файлаются на сервис специальный, и всякие мониторинговые тулзы поставлены, так что если пошли медленные транзакции, то сразу будет видно. Все средства хороши, когда надо что то быстро починить. Помню я был на плюсовых проектах где только логами пользовались. Это еще надо уметь логи писать качественно, что б по ним можно было быстро разобраться. Но ведь у плюсов нет стандартной библиотеке по записи логов. Последнее что видел из более менее приличного -*log4cpp, но и она не лишена недостатков. Вобщем если пользуются одни лишь логи, то это только от бедности.



У меня все в точности наоборот. Если код статичен - я могу нестись, как наскаровская машина по трассе. Если начинается динамика - инъекции, аспекты, рефлексия и т. д. - это все ухабы, и моя скорость падает до скорости трактора.

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

[Alex_3112]

Лог то же присутствует само собой. И лог бд, и ошибки файлаются на сервис специальный, и всякие мониторинговые тулзы поставлены, так что если пошли медленные транзакции, то сразу будет видно. Все средства хороши, когда надо что то быстро починить. Помню я был на плюсовых проектах где только логами пользовались. Это еще надо уметь логи писать качественно, что б по ним можно было быстро разобраться. Но ведь у плюсов нет стандартной библиотеке по записи логов. Последнее что видел из более менее приличного -*log4cpp, но и она не лишена недостатков. Вобщем если пользуются одни лишь логи, то это только от бедности.
А что значит "файлаются"? Это все-таки дамп идет?

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


Ну несись, я посмеюсь над тобой когда у тебя проект в несколько тысяч исходников компилится несколько часов. Сделал изменение, в хедере, и пошел домой пить чай. О, а если это мултиплатформенный проект, то его еще под каждую ОС надо собирать и это все паковать - будьте добры ставьте ферму машин для сборки. Да, конечно инструмент подобный надо ручками писать, т.к. ничего удобоваримого нет.
Да, но весь проект целиком нужно компилировать не так уж часто (я на Java пишу, так что с мультиплатформенностью мучаться особо не приходится). Даже самые большие модули компилируются почти на лету.
И даже в случе мультиплатформенности - сколько платформ должны поддерживаться одновременно?

[Yura717]

На старости лет решил обучиться программированию на языке objective-c, стоит ли начинать с этого языка?
http://ideone.com/
для элементарного обучения

[реднек]

А что значит "файлаются"? Это все-таки дамп идет?

Нет, есть сервисы наподобие exceptional.io.



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

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



Да, но весь проект целиком нужно компилировать не так уж часто (я на Java пишу, так что с мультиплатформенностью мучаться особо не приходится). Даже самые большие модули компилируются почти на лету.
И даже в случе мультиплатформенности - сколько платформ должны поддерживаться одновременно?

Был проект где с полдюжины, разные Линуксы, HPUX, AIX, Solaris, Windows, Mac OS X. Сборка дистрибутива 2 часа.

[Alex_3112]

Нет, есть сервисы наподобие exceptional.io.

Я с такими не работал. Насколько я понимаю, эти сервисы облегчают работу с большим количеством ошибок для работы в команде. Но насколько они помогают в работе с одной конкретной ошибкой?

Еще раз повторю свою мысль: это зависит не от того статический язык или динамический, а от того как написан код.
Так вот накосячить в динамическом коде в 10 раз легче. Без строгой типизации конвертации между строками, целыми и прочими переменными происходят так, что программист о них и не задумывается. Потом такая программа работает на "честном слове" и ошибки могут полезть в любую минуту.

Был проект где с полдюжины, разные Линуксы, HPUX, AIX, Solaris, Windows, Mac OS X. Сборка дистрибутива 2 часа.
В таком случае парк разных машин нужен в любом случае, верно? И компилировать в разные среды нужно для QA/Release, но не для программиста, так?

[crazy-mike]

kstati. kak jazyk piton kruche vsex! da! da! da!
piton ochen' krutoy!
Ага - язык , который сам по себе является глюком. :111:

[crazy-mike]

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

В "статическом коде" ещё легче "накосячить" ( operating environment , в котором работает такой "код" , ведь очень даже "динамическая" хреновина ). А в динамическом намного проще всё исправлять.
И "программы" там совсем не на честном слове работают. Именно компиляторы ( особенно оптимизирующие" ) делают такой "статический код" , который и в самом деле часто работает на честном слове. "Динамический код" практически никогда не столкнётся с проблемой "переполнения таблицы виртуальных методов" или ещё чего-то такого. :101:

[Alex_3112]

В "статическом коде" ещё легче "накосячить" ( operating environment , в котором работает такой "код" , ведь очень даже "динамическая" хреновина ).

Для динамического кода этот environment не становится ведь менее динамичным?

А в динамическом намного проще всё исправлять.
Возможно это субъективно, но я трачу на локализацию ошибки в статическом коде в 10-20 раз меньше времени, чем в динамическом.

И "программы" там совсем не на честном слове работают. Именно компиляторы ( особенно оптимизирующие" ) делают такой "статический код" , который и в самом деле часто работает на честном слове. "Динамический код" практически никогда не столкнётся с проблемой "переполнения таблицы виртуальных методов" или ещё чего-то такого. :101:
Динамический код зависит от прихотей интерпретатора и исполняемой среды точно так же, как статический - от компилятора и операционной системы.

[crazy-mike]

Для динамического кода этот environment не становится ведь менее динамичным?

Возможно это субъективно, но я трачу на локализацию ошибки в статическом коде в 10-20 раз меньше времени, чем в динамическом.

Динамический код зависит от прихотей интерпретатора и исполняемой среды точно так же, как статический - от компилятора и операционной системы.
В динамическом просто каждый "фрагмент кода" можно запускать(отлаживать) по отдельности. И не нужно заморачиваться так сильно с "отладочной версией проекта".
Динамический код как раз от прихотей исполняемой среды зависит намного меньше. Просто "исполняемую среду" нужно "отконфигурировать". У компилируемых всё намного хуже. Там кроме "настройки исполняемой среды" ещё и "глюки самого генератора кода" ( особенно для объектно-ориентированных и у оптимизирующих компиляторов. ).

Кроме того у "компилируемых" есть совсем другой вид ошибок - неправильно скомпилированный код ( хотя сама программа на языке программирования написана как бы правильно ). В "интерпретируемых языках" такое случается намного реже.

[реднек]

Я с такими не работал. Насколько я понимаю, эти сервисы облегчают работу с большим количеством ошибок для работы в команде. Но насколько они помогают в работе с одной конкретной ошибкой?

Как минимум говорят как часто эта конкретная ошибка происходит.


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

Ты слышал о duck-typing? Он неплохо справляется с задачей. Если тебе надо записать объект в базу, то тебе нужно пара методов: save и validate. И не надо все остальное (ну например). В статическом языке, чтобы добится этого тебе нужно иметь четко выделеный интерфейс с этими методами, как отдельную сущность, например Storable. А в куске кода, который читает объект из строки и записывает его в базу, нужен еще метод: load_from_string. Со Storable этот кусок уже работать не может и ему либо надо кросскастать, либо работать с более конкретными классами. Это я все к тому, что типизация на словах хорошо, а на практике приводит к порождению дробных типов, которые не нужны. Другой подход, который часто можно встретить - это запихать все в базовый Object. Вот там и лежат 100 методов мертвым грузом, без всякой реализации, зато избавляют от кросскастинга, и при этом дают "ощущение" проверки типов параметров.


В таком случае парк разных машин нужен в любом случае, верно? И компилировать в разные среды нужно для QA/Release, но не для программиста, так?
Так у меня программа на Руби или Питоне будет работать на Mac OS (в среде разработки) так и на Linux (продакшн).
На Java тоже, наверное, не знаю не пользую. На плюсах, надо перекомпилять под каждую платформу, часто еще под разную архитектуру процессоров.

[Alex_3112]

В динамическом просто каждый "фрагмент кода" можно запускать(отлаживать) по отдельности. И не нужно заморачиваться так сильно с "отладочной версией проекта".
А как же ситуации, когда фрагмент кода отлично работает по отдельности, но в реальных ситуациях выдает ошибки? Мы не можем "в пробирке" предусмотреть все возможные случаи.

Динамический код как раз от прихотей исполняемой среды зависит намного меньше. Просто "исполняемую среду" нужно "отконфигурировать".
При условии, что нам всегда гарантируется стандартная исполняемая среда.

У компилируемых всё намного хуже. Там кроме "настройки исполняемой среды" ещё и "глюки самого генератора кода" ( особенно для объектно-ориентированных и у оптимизирующих компиляторов. ).

Кроме того у "компилируемых" есть совсем другой вид ошибок - неправильно скомпилированный код ( хотя сама программа на языке программирования написана как бы правильно ). В "интерпретируемых языках" такое случается намного реже.
По моему опыту, "гуляющая" среда в интерпретаторах вызывает на порядки больше ошибок, чем контролируемая среда в языках типа Java. Клиент жалуется на ошибку, у меня ее нет. Приходится думать, в чем причина ошибки, может у клиента просто браузер кривой.

[crazy-mike]

Другой подход, который часто можно встретить - это запихать все в базовый Object. Вот там и лежат 100 методов мертвым грузом, без всякой реализации, зато избавляют от кросскастинга, и при этом дают "ощущение" проверки типов параметров.

Мы об этом ведь уже говорили. :116:
Но там ещё одна очень смешная вещь есть - "очень правильная объектно-ориентированная программа" со всей своей очень строгой типизацией довольно часто компилируется в просто неработающий код. ( там все эти наследования и конструкторы перепутаются так - что исполняемый код сведётся к единственной команде ret в лучшем случае ).
От таких вещей никакая строгая типизация не защищает вообще.

[crazy-mike]

А как же ситуации, когда фрагмент кода отлично работает по отдельности, но в реальных ситуациях выдает ошибки? Мы не можем "в пробирке" предусмотреть все возможные случаи.

При условии, что нам всегда гарантируется стандартная исполняемая среда.

По моему опыту, "гуляющая" среда в интерпретаторах вызывает на порядки больше ошибок, чем контролируемая среда в языках типа Java. Клиент жалуется на ошибку, у меня ее нет. Приходится думать, в чем причина ошибки, может у клиента просто браузер кривой.
По-моему опыту - у клиента практически не бывает "кривого браузера". Клиент только кеш забывает очищать. А в самом языке Java именно глюки наблюдались при переходе от одной версии к другой ( swing и awt чуть по-разному работали после перехода с 1.3 на следующую. А после появления Java FX с этой всей Java-чертовщиной лучше вообще не связываться. ). А вот у javascript всё сохранялось при обновлениях и просто чуть быстрее работать начинало. :116:

[Sixteen]

джава ваще пазорный интерпретатор п-кода. который для красоты обозвали байт-кодом.

[Alex_3112]

Ты слышал о duck-typing? Он неплохо справляется с задачей. Если тебе надо записать объект в базу, то тебе нужно пара методов: save и validate. И не надо все остальное (ну например). В статическом языке, чтобы добится этого тебе нужно иметь четко выделеный интерфейс с этими методами, как отдельную сущность, например Storable. А в куске кода, который читает объект из строки и записывает его в базу, нужен еще метод: load_from_string. Со Storable этот кусок уже работать не может и ему либо надо кросскастать, либо работать с более конкретными классами.
Определяем StorableAbstractClass где load_from_string() выбрасывает exception. И вместо Storable работаем с Abstract Class.

Приведу еще одну метафору.
Мне удобно, когда ручка лежит не в верхнем ящике стола, а прямо на столе. Не нужно открывать ящик и искать там ручку.
Мне удобно, когда папка с документами лежит не в нижнем ящике стола, а прямо на столе. Не нужно нагибаться, открывать ящик и доставать оттуда папку.
Мне удобно, когда книга, которая мне нужна, не стоит на полке, а лежит прямо на столе. Не нужно вставать со стула, идти к шкафу, брать книгу и идти обратно.
За день мне может понадобиться много папок и книг.
К концу для я могу понять, почему книги все-таки обычно стоят на полке, а папки лежат в ящике стола.
Если я не пойму этого сегодня, то на следующий день это случится точно.

[реднек]

Мы об этом ведь уже говорили. :116:
Но там ещё одна очень смешная вещь есть - "очень правильная объектно-ориентированная программа" со всей своей очень строгой типизацией довольно часто компилируется в просто неработающий код. ( там все эти наследования и конструкторы перепутаются так - что исполняемый код сведётся к единственной команде ret в лучшем случае ).
От таких вещей никакая строгая типизация не защищает вообще.

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

[реднек]

Определяем StorableAbstractClass где load_from_string() выбрасывает exception. И вместо Storable работаем с Abstract Class.

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

[Alex_3112]

По-моему опыту - у клиента практически не бывает "кривого браузера". Клиент только кеш забывает очищать. А в самом языке Java именно глюки наблюдались при переходе от одной версии к другой ( swing и awt чуть по-разному работали после перехода с 1.3 на следующую.
Это GUI, тут всего можно ожидать. А вот разница между браузерами, и даже версиями браузера может гораздо чувствительнее отражаться на JavaScript. У меня была куча примеров.

[crazy-mike]

Да, мы ходим по кругу. Продолжая по нему ходить, повторюсь, что ошибки из за несоответствия типов вылавливают совсем не так много проблем как хотелось бы. Есть еще алгоритмические ошибки, работа со внешними ресурсами, парсинг пользовательского ввода, подгрузка не тех либ, несоответствие каких нибудь pragma в хедерах, и миллион миллион всего друго, отличного от такого частного случая как неприводимость типов.
Эти ошибки несоответствия типов вообще не вылавливают собственно проблемы. В конце-концов (C++ по-варварски ) можно операцию + переопределить с параметрами void& , void& и никакой компилятор для неё не будет выдавать никаких предупреждений. :111:

[crazy-mike]

Это GUI, тут всего можно ожидать. А вот разница между браузерами, и даже версиями браузера может гораздо чувствительнее отражаться на JavaScript. У меня была куча примеров.
Как только отказались от IE у клиентов - все проблемы практически исчезли. Для всего остального просто есть "общее подмножество JavaScript+DOM" ( отличается только Drag-and-Drop в Firefox. ).

[Alex_3112]

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

Пардон, но если мы признаем наличие ситуации, что объект может не поддерживать какую-то функцию, мы должны справляться с этой ситуацией в runtime. Непринципиально, ловим мы exceptions или пишем if-else. Важно, что если просходит ошибка, мы всегда знаем, какой исходный файл открыть и увидеть, откуда эта ошибка взялась.

[Alex_3112]

Как только отказались от IE у клиентов - все проблемы практически исчезли.
Эх, не все могут позволить себе такую роскошь :)

[реднек]

Эти ошибки несоответствия типов вообще не вылавливают собственно проблемы. В конце-концов (C++ по-варварски ) можно операцию + переопределить с параметрами void& , void& и никакой компилятор для неё не будет выдавать никаких предупреждений. :111:

Правда чтоль? Помнится плюсы более "строги".

[реднек]

Пардон, но если мы признаем наличие ситуации, что объект может не поддерживать какую-то функцию, мы должны справляться с этой ситуацией в runtime. Непринципиально, ловим мы exceptions или пишем if-else. Важно, что если просходит ошибка, мы всегда знаем, какой исходный файл открыть и увидеть, откуда эта ошибка взялась.

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

[Sixteen]

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

[Sixteen]

bi efreid! bi veri efreid!

[crazy-mike]

даёш динамическиы ци!

Есть. Не меньше четырёх реализаций под Linux.
tcc ( Tiny C++ ) и ещё несколько. Я этой хреновиной даже пользовался когда-то давно.
Мелькал ещё Object REXX - но это уже больше на "динамический PL/1" было похоже.

[Alex_3112]

Ну так и в динамическом - то же самое, открываешь файл и смотришь где ошибка взялась. Или ловишь экцепшн и смотришь его стэктрейс. И тела функций еще можно посмотреть, а не только имена.
А какой файл открываешь, вот в чем вопрос.
В статическом языке стэктрейс однозначно указывает на файл и строку, где произошла ошибка. А на что указывает стэктрейс в динамическом?

[реднек]

А какой файл открываешь, вот в чем вопрос.
В статическом языке стэктрейс однозначно указывает на файл и строку, где произошла ошибка. А на что указывает стэктрейс в динамическом?

To же самое, файл и строку.

[crazy-mike]

To же самое, файл и строку.
Только с одной большой разницей - в "динамическом" указывает на то , что в самом деле выполнялось. А в статическом указывает на то , что могло бы выполняться. ( сгенерированый код отладочной версии не совпадает с рабочим. И если уже совсем точно - то "код для отладчика" часто является p-кодом (u-кодом , o-кодом и т.д. Особенно меня в этом контексте "улыбает" Java ) , который является и "динамическим" , и "интепретируемым". :111: ).

[Alex_3112]

To же самое, файл и строку.
А если код, где произошла ошибка, сгенерирован динамически?

[Alex_3112]

сгенерированый код отладочной версии не совпадает с рабочим.
Очень экзотические случаи, по моему опыту. Только если что-то неоткомпилировалось.

А указания на то, что действительно выполнялось, в случае динамического кода напоминают мне анекдот:



- Где Африка?
- Там!
- А где "там"?
- Можно только один вопрос задавать!

[реднек]

А если код, где произошла ошибка, сгенерирован динамически?

Зависит от того как был сгенерен динамический код. Если динамически были подгружены модули с методами и вставлены в объект или класс, и ошибка в одном из таких методов, то покажет на фаил со строкой где этот метод содержиться. Если же это динамическое интерпретирование строки содержащей код (а ля eval), то покажет на место где строка генерится (это не очень приятно, да). Есть еще способы, как берется метод переназывается, на его месте создается новый который вызывает старый и еще чего то там делает, там то же все видно в каком месте произошло. Возможно функцию проэвалюировать в контексте объекта или класса, там тоже все видно, т.к. тело функции явно прописано. Самый противный случай это вышеупомянутый eval строки, но в него редко попадаешь. Кстати, не приходилось смотреть ошибку в плюсах в коде сгенерированом директивами препроцессора? Стэк препроцессора не показывается ведь, еще похуже eval, будет. Ну как инстанциируются шаблоны в замечательном статическом C++, еще можно отследить, но лучше иметь сразу 30 дюймовый монитор, что бы поместилось сообщение об ошибки компиляции.

[реднек]

Alex, я кажется понял твое предубеждение к динамическим языкам. Динамический, это не значит, что код сгенерирован и непонятно откуда ноги растут. Нет. Динамический это означает что объекты и классы могут обретать новые методы по ходу жизни, или меняется механизм поиска существующих. При этом телеса этих методов доступны и будут показаны в трейсе. eval(строка) пользуется редко, я никогда не пользую его, и вообще это рассматривается как bad practice. А то что цепочка поиска метода меняется - это не страшно. Сравни например с построенной цепочкой декораторов в статическом языке - они сами имеют четкие типы, но то как выстроена цепочка зависит полностью от runtime.

[crazy-mike]

Очень экзотические случаи, по моему опыту. Только если что-то неоткомпилировалось.

совсем не экзотические - оно как бы компилируется , но после "оптимизационных процедур компилятора" вообще не остаётся ни одной исполняемой инструкции. Например , если значение локальной переменной после первого присваивания внутри процедуры вообще не изменяется до самого выхода из процедуры , то код для оператора присваивания ( mov ...) не генерируется вообще. Особенно если "память" для переменных заполняется "директивами" ( db и т.п. ).
Просто "семантика инструкции присваивания" ведь состоит в вызове процедуры копирования значения. В описанном случае "семантика инструкции присваивания" не соответствует генерируемому коду.

[реднек]

совсем не экзотические - оно как бы компилируется , но после "оптимизационных процедур компилятора" вообще не остаётся ни одной исполняемой инструкции. Например , если значение локальной переменной после первого присваивания внутри процедуры вообще не изменяется до самого выхода из процедуры , то код для оператора присваивания ( mov ...) не генерируется вообще. Особенно если "память" для переменных заполняется "директивами" ( db и т.п. ).
Просто "семантика инструкции присваивания" ведь состоит в вызове процедуры копирования значения. В описанном случае "семантика инструкции присваивания" не соответствует генерируемому коду.
Все правильно, функция имеет возвращаемое значение и side-effects. Если оптимизация не влияет не на то не на другое, то почему бы ее не применить. Семантика функции не изменится с точки зрения языка.

[crazy-mike]

Все правильно, функция имеет возвращаемое значение и side-effects. Если оптимизация не влияет не на то не на другое, то почему бы ее не применить. Семантика функции не изменится с точки зрения языка.
Ага. Не изменится. Вот только "выполнение с точки зрения статического языка" в таких случаях совсем не соответствует "выполнению кода". Вообще никак. И break на инструкции присваивания , для которой вообще не генерировался "исполняемый код" , является чем-то "совсем странным" (т.е. желательно генерировать хотя бы команду nop :111: ). У "динамических языков" такого "глюка" практически не бывает. :101:

[реднек]

Ага. Не изменится. Вот только "выполнение с точки зрения статического языка" в таких случаях совсем не соответствует "выполнению кода". Вообще никак. И break на инструкции присваивания , для которой вообще не генерировался "исполняемый код" , является чем-то "совсем странным" (т.е. желательно генерировать хотя бы команду nop :111: ). У "динамических языков" такого "глюка" практически не бывает. :101:

А где ты видил чтобы отлаживали соптимизированый код?

[Alex_3112]

совсем не экзотические - оно как бы компилируется , но после "оптимизационных процедур компилятора" вообще не остаётся ни одной исполняемой инструкции. Например , если значение локальной переменной после первого присваивания внутри процедуры вообще не изменяется до самого выхода из процедуры , то код для оператора присваивания ( mov ...) не генерируется вообще. Особенно если "память" для переменных заполняется "директивами" ( db и т.п. ).
Просто "семантика инструкции присваивания" ведь состоит в вызове процедуры копирования значения. В описанном случае "семантика инструкции присваивания" не соответствует генерируемому коду.

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

[Alex_3112]

Alex, я кажется понял твое предубеждение к динамическим языкам. Динамический, это не значит, что код сгенерирован и непонятно откуда ноги растут. Нет. Динамический это означает что объекты и классы могут обретать новые методы по ходу жизни, или меняется механизм поиска существующих.
Эх, хорошо. когда все вот так вот, четко и аккуратно! Но я пытаюсь только сказать, что в динамическом языке возможности развести путаницу очень широкие.

И еще веселее, когда javascript, в котором происходит ошибка, minified (а у нас в продакшне именно так). "Ошибка в строке 1" - а весь файл состоит из одной строки :)

[crazy-mike]

А где ты видил чтобы отлаживали соптимизированый код?
Нигде. Но мы когда-то тестировали по договору оптимизирующий компилятор с языка C для какого-то идиотского микропроцессора. :116:
Там тесты нужно было именно через оптимизирующий компилятор пропускать.

[crazy-mike]

Нет, я не спорю, что такие случаи бывают, просто в Java мне с этим очень и очень редко приходится сталкиваться.
Но называть Java - "статический язык со строгой типизацией"?????? Там ведь это больше от "стиля программирования" зависит. :116:

[реднек]

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

И еще веселее, когда javascript, в котором происходит ошибка, minified (а у нас в продакшне именно так). "Ошибка в строке 1" - а весь файл состоит из одной строки :)

У всех в продакшене minified javascript, есть такая штука как source-mapping, чтобы можно было оттрайсить в оригинальном неминифицированом исходнике: http://www.thecssninja.com/demo/source_mapping/

[реднек]

Нигде. Но мы когда-то тестировали по договору оптимизирующий компилятор с языка C для какого-то идиотского микропроцессора. :116:
Там тесты нужно было именно через оптимизирующий компилятор пропускать.

Оптимизатор может вообще убрать функцию и сгенерить ее инлайн.

[crazy-mike]

Оптимизатор может вообще убрать функцию и сгенерить ее инлайн.
если бы только это. Он ведь и "объект" может убрать вообще. :111:
А когда "оптимизатор" начинает "оптимизировать порядок вычисления выражения"....:111:

[реднек]

если бы только это. Он ведь и "объект" может убрать вообще. :111:
А когда "оптимизатор" начинает "оптимизировать порядок вычисления выражения"....:111:

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

[Радригес]

начни с Python самый простой язык для изучения ..... и области применения у него большие ....
Python поддерживает несколько парадигм программирования, в том числе структурное, объектно-ориентированное, функциональное, императивное и аспектно-ориентированное. Основные архитектурные черты — динамическая типизация, автоматическое управление памятью, полная интроспекция, механизм обработки исключений, поддержка многопоточных вычислений и удобные высокоуровневые структуры данных. Код в Питоне организовывается в функции и классы, которые могут объединяться в модули (которые в свою очередь могут быть объединены в пакеты).
https://www.coursera.org/course/interactivepython
This course is designed to help students with very little or no computing background learn the basics of building simple interactive applications. Our language of choice, Python, is an easy-to learn, high-level computer language that is used in many of the computational courses offered on Coursera. To make learning Python easy, we have developed a new browser-based programming environment that makes developing interactive applications in Python simple. These applications will involve windows whose contents are graphical and respond to buttons, the keyboard and the mouse.

Все верно. Питон прост для начала. После него будет легче.

[Alex_3112]

Но называть Java - "статический язык со строгой типизацией"?????? Там ведь это больше от "стиля программирования" зависит. :116:

Ну если баловаться с рефлексией, то и из Java можно сделать балаган :)

[Alex_3112]

У всех в продакшене minified javascript, есть такая штука как source-mapping, чтобы можно было оттрайсить в оригинальном неминифицированом исходнике: http://www.thecssninja.com/demo/source_mapping/

Нет, можно конечно выйти из положения (я например пользуюсь deminifier plugin). Но нужно ли создавать себе дополнительные сложности?

[crazy-mike]

Ну если баловаться с рефлексией, то и из Java можно сделать балаган :)
Да. Но там и без этого балаган: цирк = (балаган) дурдом и т.д.
:116:

[crazy-mike]

Ага, поэтому всякий минимально развитый плюсовый программист должен держать в голове понятие sequence points.
Ага. Голова у программиста - не токмо sequence points держать ( concurrent event handling , например...). :101:

[реднек]

Все верно. Питон прост для начала. После него будет легче.

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

[crazy-mike]

Поддержу Питон. Более строгий и более бедный чем Руби, хотя во многом и похож, меньше магии, огромная коммьинити, хорошая документация, нет такого многообразия стилей как в JavaScript, динамический, достаточно быстрый, дружит с Windows, то что надо для новичка.
Мне вообще-то всё больше C без всяких ++ нравится. И даже sh почему-то. А всю эту объектную муть использую в основном как namespaces.