|
26.09.2014, 02:29 | #1 |
Banned
|
Цитата:
JavaFX или Swing GUI библиотеками? Там уже не до красивостей будет. То есть я понимаю что речь лишь об обогащении X++ или С#, но мы же не рассчитываем траекторию нейронов для коллайдера, у нас все от GUI и для GUI. Все что нужно бойцу на реальном фронте бизнес-приложений это GUI ориентированные инструменты и удобство работы с базой данной. И боевой программист, тот который в окопе на линии огня, при всей своей любви к прекрасному С++ будет рад тому же Visual Studio и даже Visual Basic именно из-за GUI и удобства работы с данными. Потому как в окопе прекрасное только сниться. Тому же MorthX и X++ цены нет если смотреть на разработку не как на кодинг а как на продукт вашего труда у которого основной фокус на потребителе, а не на невидимом совершенстве которого никто не оценит. Неудовлетворение X++ и желание перейти на более "мощные" языки я понять не могу. Меня гораздо больше волнует корректная генерация HTML5 в версии AX2015 и надежность среды выполнения в целом чем "мощность" языка выраженная в более коротких конструкциях кода. Тот же СSS на вашу репутацию программиста окажет большее влияние чем хитрый выверт кода которым вы будете долго гордится И возможно из-за которого система будет время от времени падать, она вообще часто любит в обморок от красивостей падать |
|
|
За это сообщение автора поблагодарили: macklakov (7). |
26.09.2014, 16:54 | #2 |
Разработчик
|
Цитата:
Сообщение от ax_mct
И этими наглядными короткими математическими формулами вы будете рисовать и работать с GUI? Или 20 минут на прекрасное наряду с парой дней на копание с
JavaFX или Swing GUI библиотеками? Там уже не до красивостей будет. То есть я понимаю что речь лишь об обогащении X++ или С#, но мы же не рассчитываем траекторию нейронов для коллайдера, у нас все от GUI и для GUI. Все что нужно бойцу на реальном фронте бизнес-приложений это GUI ориентированные инструменты и удобство работы с базой данной. И боевой программист, тот который в окопе на линии огня, при всей своей любви к прекрасному С++ будет рад тому же Visual Studio и даже Visual Basic именно из-за GUI и удобства работы с данными. Потому как в окопе прекрасное только сниться. Тому же MorthX и X++ цены нет если смотреть на разработку не как на кодинг а как на продукт вашего труда у которого основной фокус на потребителе, а не на невидимом совершенстве которого никто не оценит. Длинный и многострочный код не способствует ни надежности, ни математической ясности, ни скорости кодинга. Для достижения прогресса в этом направлении кода должно быть меньше и он должен быть более читаемым и более строг в математическом изложении при этом, чем тот что ранее был длинным и многострочным и неочевидным при беглом чтении. Программист прикладных систем - многостаночник, ему все равно с какой системой работать, главное чтобы удобно и быстро было ему писать, отлаживать и реже делать ошибки, тогда и заказчик (клиент) тоже будет доволен и языком и программистом. X++ увы, как и модный C#, не являются таковыми, хотя широко другие языки и не используются пока ещё. На счет GUI и в частности веб-интерфейса для приложений: http://habrahabr.ru/post/152067/ Цитата:
Когда вы пишете на Lift вы пишите раза в 2-3 меньше кода, чем если бы писали на java-фреймворке (например один прогер переписал свой проект с Play на Lift, на Play у него реализация заняла 24k строк, а на Lift 6k). А если сравнивать с фреймворками типа Spring MVC / Struts то разница будет еще больше.
Последний раз редактировалось perestoronin; 26.09.2014 в 17:01. |
|
27.09.2014, 00:52 | #3 |
Banned
|
Цитата:
Сообщение от perestoronin
Ценность кода (как результата труда программиста) - как легко Вы его сами сможете прочитать как автор и сколько времени потребуется на его восприятие Вам же скажем через год, или сколько времени нужно, чтобы Ваш код понял другой разработчик, или сколько времени нужно чтобы Вы поняли код другого разработчика.
Редкий код нельзя прочитать и понять. Всегда понятно что код делает (в машинном смысле) даже если он не оптимизирован или грязно написан. Но практически всегда возникают вопросы "зачем" с точки зрения решаемой задачи. И тут все равно в разы там меньше или больше кода в отдельно взятом методе/функции. Что действительно имеет значение так это программный дизайн решения, распределение кода по методам и объектам, соответственное их наименование. Только это и может помочь понять что как работает решение (наряду с комментариями в коде). А проблема чтения строчек кода в отдельно взятом методе - это не существующая трудность. Цитата:
Сообщение от perestoronin
Длинный и многострочный код не способствует ни надежности, ни математической ясности, ни скорости кодинга.
Для достижения прогресса в этом направлении кода должно быть меньше и он должен быть более читаемым и более строг в математическом изложении при этом, чем тот что ранее был длинным и многострочным и неочевидным при беглом чтении. В X++ все есть для реализации такого счастья. Цитата:
Сообщение от perestoronin
Программист прикладных систем - многостаночник, ему все равно с какой системой работать, главное чтобы удобно и быстро было ему писать, отлаживать и реже делать ошибки, тогда и заказчик (клиент) тоже будет доволен и языком и программистом.
X++ увы, как и модный C#, не являются таковыми, хотя широко другие языки и не используются пока ещё. То есть вы не обижайтесь, но программист с коммерческим опытом (то есть не зеленый студент прочитавший взахлеб все три тома Дональда Кнута) такое не напишет (на мой взгляд). Но я вам очень благодарен за поддержание дискуссии, в обмене мнений учатся все и я не исключение. Просто мы какие то очень разные и я пытаюсь понять в чем дело. Цитата:
Сообщение от perestoronin
На счет GUI и в частности веб-интерфейса для приложений:
http://habrahabr.ru/post/152067/ "Когда вы пишете на Lift вы пишите раза в 2-3 меньше кода". То что в методе вместо 30 строк будет 10 строк - это на что влияет? Скорость чтения кода повышается в три раза? Не влияет "мощность" языка (то есть его более лаконичные или даже более "математические" конструкции) на скорость программирования и стоимость разработки. Если и влияет то в отрицательную сторону. Так же как и разгон супермощного автомобиля в два раза быстрее (4 сек вместо 8 сек) и на 100 км/ч большая максимальная скорость (250 км/ч вместо 150 км/ч ) ни на что не влияют в реальных городских условиях. Приятно конечно за рулем посидеть но собственно и все. Так и собственно в реальном мире программирования происходит - оптимальный маршрут и грамотное вождение. А Форд это или Феррари - нерелевантно. Последний раз редактировалось ax_mct; 27.09.2014 в 01:20. |
|
|
За это сообщение автора поблагодарили: S.Kuskov (2). |
25.09.2014, 17:40 | #4 |
Участник
|
http://www.nestor.minsk.by/sr/2003/07/30710.html
Когда наш гипотетический Блаб-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем Блаб, языки явно менее мощны, так как в них нет некой особенности, к которой привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто "странные" языки. Возможно, он считает их одинаковыми с Блабом по мощности, но со всяческими сложными штучками. Блаба для нашего программиста вполне достаточно, так как он думает на Блабе. |
|
|
За это сообщение автора поблагодарили: AlexeyS (1). |
25.09.2014, 17:58 | #5 |
Разработчик
|
Цитата:
Если требовались программисты на Perl или Python, это уже было слегка пугающе — это значило, что компанией или, по крайней мере, ее технической частью заправляли настоящие хакеры. Если бы я когда-нибудь увидел объявление о найме на работу Lisp-хакеров, я бы обеспокоился не на шутку.
Если элементы ФП пригодны и для написания корпоративных приложений: http://habrahabr.ru/post/212121/ то почему бы их не использовать и в X++ ? Например - для продления привлекательности X++, хотя конечно можно жить хорошо пользуясь всего лишь языком более низкого уровня, как у 1С-ки к примеру. Последний раз редактировалось perestoronin; 25.09.2014 в 18:10. |
|
25.09.2014, 18:43 | #6 |
Гость
|
Цитата:
Сообщение от belugin
http://www.nestor.minsk.by/sr/2003/07/30710.html
Когда наш гипотетический Блаб-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем Блаб, языки явно менее мощны, так как в них нет некой особенности, к которой привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто "странные" языки. Возможно, он считает их одинаковыми с Блабом по мощности, но со всяческими сложными штучками. Блаба для нашего программиста вполне достаточно, так как он думает на Блабе. Тот кто, решает задачу с помощью менее мощного языка, вынужден прописывать в своем тексте больше подробностей (например, программисты на различных ассемблерах в этих подробностях просто тонут). А значит он об этих подробностях осведомлен. Тот, кто решает задачу с помощью более мощного языка, как правило даже не догадывается, сколько всего происходит за кулисами. Он отделен от происходящего толстой стеной из абстракций. И когда происходит нечто, выходящее за рамки этих абстракций, такой программист ничего не может сделать. Есть же известная статья на эту тему http://russian.joelonsoftware.com/Ar...tractions.html Так что в вашей цитате верх и низ перепутаны местами. P.S. Самый мощный язык программирования таков, что программы на нем состоят из одного пробела и решают неограниченный круг задач. Это серебряная пуля и красная кнопка в одном флаконе, точнее в чаше Грааля. Но непонятно, как найти ошибку в программе из одного пробела, если вдруг она перестанет работать как от нее ожидают. |
|
25.09.2014, 18:58 | #7 |
Участник
|
Цитата:
Сообщение от Кирилл
Тот, кто решает задачу с помощью более мощного языка, как правило даже не догадывается, сколько всего происходит за кулисами. Он отделен от происходящего толстой стеной из абстракций. И когда происходит нечто, выходящее за рамки этих абстракций, такой программист ничего не может сделать.
Кстати, Джоэл почему-то предпочел сделать свой более мощный язык: Since we are not blub programmers, we like closures, active records, lambdas, embedded SQL a la LINQ, etc. etc. and so those are the kinds of features we put into Wasabi. Задача причем весьма прикладная и информационная - багтрекер. Цитата:
Но непонятно, как найти ошибку в программе из одного пробела, если вдруг она перестанет работать как от нее ожидают.
Последний раз редактировалось belugin; 25.09.2014 в 19:07. |
|
25.09.2014, 19:48 | #8 |
Гость
|
Цитата:
А по-хорошему надо сравнивать действующие языки. C++ и C# к примеру. С# программист не напишет более быстрое вычисление чего-либо, чем C++ программист. |
|
25.09.2014, 19:58 | #9 |
Разработчик
|
Достигается в плане реализации не на языках C# или C++.
PS. Скорее это удел многоядерного программирования на ассемблере, или на Fortran , а также надстройки над С++ и C в виде технологии от Nvidia CUDA. Речь не о том, что scala (как и все языки ФП) имеет поддержку параллельной обработки данных, а о том, чтобы программисту было комфортно быстро писать надежный более легкий в понимании и чтении код. Почему бы не достичь такого же результата и в X++ немного усовершенствовав его (в плане краткости, возможности беглого чтения кода, надежности) ? Последний раз редактировалось perestoronin; 25.09.2014 в 20:12. |
|
25.09.2014, 20:11 | #10 |
Участник
|
Цитата:
OK давайте C++ и Plain C. Подсказка: - Язык X может включать все возможости языка Y + еще высокоуровневые возможности - На языке X можно написать eDSL с кодогенерацией как у Y (например Forth Assembler, WebSharper и т.д.) - Программист на Языке X может так же знать и Y и использовать его по мере надобности |
|
25.09.2014, 20:02 | #11 |
Гость
|
Цитата:
Еще час назад наш пробел отлично работал, что же делать? Наверно стоит отправить запрос разработчикам компилятора. |
|
25.09.2014, 20:11 | #12 |
Гость
|
Цитата:
Сообщение от belugin
Кстати, Джоэл почему-то предпочел сделать свой более мощный язык:
А тот, кто сел сразу за более мощный, о многом происходящем не догадываются. |
|
25.09.2014, 20:27 | #13 |
Гость
|
Я веду к тому, что появление языков все более высокого уровня в итоге порождает программистов все более низкого уровня.
Хорошо, если программист - это бородатый дяденька, который развивался вместе с развитием языков, он знает, что стоит за новой абстракцией и как конкретно эта абстракция облегчила его жизнь и он помнит как можно жить без нее. А что делать школьнику? Проходить за пару лет жизненный путь бородатого дяденьки или взять учебник по c# ? И это не только к языкам программирования относится, а к технологиям вообще. Выключите электричество и современная цивилизация умрет. Последний раз редактировалось Кирилл; 25.09.2014 в 20:29. |
|
26.09.2014, 02:43 | #14 |
Banned
|
Цитата:
Кто то пишет программы для микроконтроллеров или системные библиотеки. Вот они как раз и программисты низкого уровня А образование штука такая - то что вчера в вузе месяцами рассказывали сегодня в 10 минутном мультике ребенок смотрит при том же понимании вопроса |
|
26.09.2014, 04:21 | #15 |
NavAx
|
В кои то веки согласен с ax_mct
Можно много и умно рассуждать о красоте и мощи языков. Но дело ведь не в скромненьком X++, а в MorphX. Замена наглядного "программирования мышкой" на нечитаемых кадавров автогенерированного кода из VS это откровенная деградация продукта. Точно так гипер-нормализация привела к нечитаемости базы данных и диким гемороем с сопровождением настроек. Лучше бы вместо "архитекутрных усовершенствований" привинтили контроль версий для настроек. Или изолировали конфигурации и настройки в одтельной базе данных. Ведь ERP это, в первую очередь, "программирование галочками".
__________________
Isn't it nice when things just work? |
|
26.09.2014, 06:33 | #16 |
Участник
|
|
|
26.09.2014, 10:37 | #17 |
NavAx
|
Вот именно. Но в 2012 как-то так получилось что перенося свистелки и перделки сомнительной ценности из .Net, MorphX малость погнули, где-то даже поломали. Отсюда и проистекает немного нервная реакция на нововведения.
__________________
Isn't it nice when things just work? |
|
|
За это сообщение автора поблагодарили: eugene egorov (2). |
26.09.2014, 12:50 | #18 |
Участник
|
|
|
26.09.2014, 08:55 | #19 |
Участник
|
Вот, кстати, пример
Программист использует вполне допустимую конструкцию, которую пропускает компилятор, но валится дебаггер. В случае если бы языком пользовалась гораздо большая толпа, это не было бы "угловым случаем" и багу давно бы пофиксили и абстракция стала менее дырявой. В данном случае вместо этого, у X++ программиста формируется чутье, которое призывает его избегать необычных конструкций. |
|
26.09.2014, 14:52 | #20 |
Участник
|
За не всегда работающие диналинки - руки бы поотрывал
__________________
Axapta v.3.0 sp5 kr2 |
|
Теги |
.net, aot, cil, layer, morphx, x++, компилятор, слои |
|
Похожие темы | ||||
Тема | Ответов | |||
Прощай, CITP-AT / Software-Vertriebsfirma Columbus IT Partner programmiert Pleite | 3 |
|