Какой ЯП более гибкий.

[leo_bsv]

Троллефобия?

BolgenOфобия...

[FedeX]

Насчёт опенсурса с нормальным бд и гюи - это все про Java. Гибкость - тоже про неё, нричём продуманная гибкость с чёткой типизацией, как в паскале, с минимумом ненужных конструкций (ненавижу все эти питоновские выпендрёжы - лучше написать больше кода, но чтоб он читался как художественное произведение, а не как замысловатая шифровка). С чем у явы плохо, так с потреблением памяти. Ну и из первой проблемы вытекает вторая - галимая портируемость программ на мобильные платформы - фактически для Android, J2ME, Blackberry надо писать отдельные приложения.. Ещё лучше явы в плане синтаксиса и гибкости - Scala.

Хотя, конечно чего бы язык не позволял никто кроме самого разработчика не заставит его писать чистый читабельный код. Вот недавно у нас в комманде вебщиков был спор насчёт принятия стандартов кодирования внутри комманды. Спор разгорелся вокруг двух идентичных по смыслу конструкций:

var x = some;
function x(){doSome(); return some;}

1) x && x();
2) if (x){
x();
}

Несколько человек уперлись рогом, что они хотят и будут писать вариант 1) потому, что так скорее и по их мнению понятней, не смотря, что большинство проголосовало за более читабельный вариант 2). Проблема в том, что любой код должен иметь аналог в устной человеческой речи (тогда он будет понятен максимальному количеству людей которые возможно даже не знают этого языка программирования) и код 2 удовлетворяет этому условию, а код 1 - нет. По этому принципу и создавался Паскаль - в него даже вносились излишества, так нелюбимые сишниками - всё только для того, чтобы код более походил на устную речь и был более чистым и понятным.
Так что те программисты, которые отстаивали вариант 1) были признаны еретиками и были торжественно сожжены на костре. Шутю

[alexey38]

Синтаксический сахар нельзя забывать, например функция возвращает перечисляемый объект и этот результат мы раскидываем по переменным, затем делаем цикл с автоматическим целочисленным индексом:

Код: Выделить всё

def myfunc():
    return 'qwe'
a, b, c = myfunc()
for i, v in enumerate(myfunc()):
    print '%d:%s'%(i, v)  # 0:q 1:w 2:e


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

Данный пример, как раз демонстрация слабости Питона. Функционал очень неявно выражен, не видя содержимого Myfunc вообще не догадаешься, что должно произойти. Такой код в сопровождении будет очень дорого стоить. Паскалевская строгость типов здесь как раз идеально демонстрирует слабость Питона. Длина паскалевского кода не будет значительно превышать питоновсокго, зато будет 100% ясность.

[Mr.Smart]

BolgenOфобия...

Юношеский максимализм, подумаешь. Зачем его бояться?

[stikriz]

Насчет гибкости - этот термин мне вообще никогда не был понятен.

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

О чем вы тут все?

Добавлено спустя 11 минут 53 секунды:

А теперь серьезно, задумайтесь все что имеет дисплей и больше 3-х кнопок имеет под собой проц с частотой выше 200 Мгц, и в 90% случаев там живет ядро Linux-a.

Откуда инфа? Смахиваю слезу от гордости и счастья за линукс

[leo_bsv]

Юношеский максимализм, подумаешь. Зачем его бояться?

... не за юношу, за Державу обидно

[bw]

FedeX> Насчёт опенсурса с нормальным бд и гюи - это все про Java
Или про Jython :-) ?

FedeX> лучше написать больше кода, но чтоб он читался как художественное произведение
Это так что-ли?

Код: Выделить всё

var
  result: String;
  a, b, c: Char;
begin
  result := myfunc();
  a := result[1];
  b := result[2];
  c := result[3];


FedeX> Спор разгорелся вокруг двух идентичных по смыслу конструкций
Хороший пример. Если честно я тоже временами метаюсь из стороны в сторону, как же всё же писать. (То что конструкция с if'ом читабельнее, спорное утверждение.)

alexey38> не видя содержимого Myfunc вообще не догадаешься, что должно произойти
Т.е. ты, что бы использовать функцию пользуешься хедерами, странный подход, мне достаточно справочной документации по API, где сказано что myfunc всегда возвращает перечисляемый тип (в данном случае строку) с тремя элементами.
alexey38> Паскалевская строгость типов здесь как раз идеально демонстрирует слабость Питона
А ещё есть мнение что она нужна лишь криворуким программистом, которые не пользуются документацией, а ждут подсказки от компилятора. В общем я не понял тебя, что она там в данном случае демонстрирует, я же не наобум метод вызываю, мне известны входные параметры и результат, думаю ты так же поступаешь.

..bw

[FedeX]

>Это так что-ли?
Именно! Этот код на 150% читабельнее постороннему программисту. Когда я делаю кодревью, я не хочу и не буду метаться по документации - у меня нет на это времени. В идеале мне вообще неинтересно содержимое и описание функции myfunc - о том что она делает должны исчерпывающе повествовать её название, типы передаваемых параметров и тип результата. По этой же причине я иногда создаю промежуточные переменные с названиями, говорящими о том что сейчас происходит с данными (несмотря на то, что зачастую это приводит к разбуханию однострочного выражения на 10 строк простого и понятного кода), и по этой же причине слежу чтобы в одной функции по возможности не скапливалось более допустим 20 строк кода иначе выношу его в отдельные функции/классы. То что такой код возможно будет чуть менее быстрый в 99,9% случаев никак не отразится, зато сопровождать такой код в десятки раз проще. имхо, конечно

[bw]

bw> Это так что-ли?
FedeX> Именно!
Ну так тоже на Python писать можно. Контроль типов организовать можно (пусть ограниченный и в runtime), проверку входных параметров функции и её результатов тоже (контракты), интерфейсы, адаптеры, импорт из любых источников (да хоть генерирование на лету) и т.д. и т.п. Возможность всего этого и говорить о гибкости языка (в этой теме мы именно гибкость, что бы это не было, обсуждаем).

FedeX> Этот код на 150% читабельнее постороннему программисту.
Субъективное утверждение.

FedeX> я не хочу и не буду метаться по документации - у меня нет на это времени
Я тоже не всегда заглядываю в документацию.

p.s. Я больше 10 лет работал на Pascal (начиная примерно с 95'го), тем не менее решил попробовать Python, после чего перешёл на него полностью, не жалею. Думаю что я имею право судить о плюсах и минусах обоих этих языков. И не когда не противопоставлял их друг другу. Но что касается гибкости, то это всё же Python.

..bw

[alexey38]

alexey38> не видя содержимого Myfunc вообще не догадаешься, что должно произойти
Т.е. ты, что бы использовать функцию пользуешься хедерами, странный подход, мне достаточно справочной документации по API, где сказано что myfunc всегда возвращает перечисляемый тип (в данном случае строку) с тремя элементами.
alexey38> Паскалевская строгость типов здесь как раз идеально демонстрирует слабость Питона
А ещё есть мнение что она нужна лишь криворуким программистом, которые не пользуются документацией, а ждут подсказки от компилятора. В общем я не понял тебя, что она там в данном случае демонстрирует, я же не наобум метод вызываю, мне известны входные параметры и результат, думаю ты так же поступаешь.
..bw

Если пишешь одноразовую программу, то можно как угодно. Если реальный проект либо долгий, либо командный, то возникает куча проблем.
Кто своевременно и безошибочно напишет документацию, где будет сказано про MyFunc? И самое главное, каковы будут затраты на документацию?

На паскале секция интерфейса по MyFunc с комментариями по сути (прикладной уровень) уже является документацией. Ее на 100% достаточно. И главное нечеткость изъяснения в комментариях покрывается строгостью типов.
На питоне при написании программы сэкономишь 3 строки (10 секунд времени при кодировании), но потратишь часы на написание доки.
Даже сам програмер может забыть что он хотел сделать. Если он сразу не написал комментарий, то он сам не сможет понять, что должна делать MyFunc. В итоге нужно смотреть реализацию метода, смотреть примеры использования.

Если паскалевский аналог кода, то вывод на печать будет занимать те же строки, что и на питоне, т.к. к строке можно адресоваться как к массиву. Если нужны отдельные переменные-символы для элементов строки, то явное присваивание будет нагляднее. И главное, как будет работать питоновский код, если функция вернет что-то другое: число, 2 символа, или 10 символов?

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

Добавлено спустя 5 минут 8 секунд:

>Это так что-ли?
Именно! Этот код на 150% читабельнее постороннему программисту. Когда я делаю кодревью, я не хочу и не буду метаться по документации - у меня нет на это времени. В идеале мне вообще неинтересно содержимое и описание функции myfunc - о том что она делает должны исчерпывающе повествовать её название, типы передаваемых параметров и тип результата. По этой же причине я иногда создаю промежуточные переменные с названиями, говорящими о том что сейчас происходит с данными (несмотря на то, что зачастую это приводит к разбуханию однострочного выражения на 10 строк простого и понятного кода), и по этой же причине слежу чтобы в одной функции по возможности не скапливалось более допустим 20 строк кода иначе выношу его в отдельные функции/классы. То что такой код возможно будет чуть менее быстрый в 99,9% случаев никак не отразится, зато сопровождать такой код в десятки раз проще. имхо, конечно

Полностью поддерживаю. Хороший код - сам является документацией. Словесное дополнение - это только по прикладному уровню и предметной области. Я беру свой код 10 летней давности и сопровождаю его как будто писал вчера, и это не из-за каких-то сверхспособностей. Отдельной доки на код нет. На задачу для пользователя (не для программиста) есть.

Добавлено спустя 7 минут 6 секунд:

bw> Это так что-ли?
FedeX> Именно!
Ну так тоже на Python писать можно. Контроль типов организовать можно (пусть ограниченный и в runtime), проверку входных параметров функции и её результатов тоже (контракты), интерфейсы, адаптеры, импорт из любых источников (да хоть генерирование на лету) и т.д. и т.п. Возможность всего этого и говорить о гибкости языка (в этой теме мы именно гибкость, что бы это не было, обсуждаем).
..bw

Дословно Вы говорите о том, что в отличие от паскаля, питон менее гибок, в нем возможно организовать контроль типов только в runtime. В паскале сам выбираешь либо строгую типизацию, а можешь использовать тот же variant (что и используется в питоне). Так что начало Вашей фразы противоречит выводам.

Единственное, что есть в питоне - это хитро-гонные конструкции "a, b, c = myfunc()" с очень не очевидным функционалом. Если его дополнить проверками, на типы и число возвращенных элементов, то длина кода на паскале и питоне будет одинакова. Что и следовало ожидать. Гибкость есть только для одноразового кода. А качественный код со всеми проверками не зависит от языка. Вся разница в том, что паскаль помогает кодить путем проверки типов на этапе компиляции. А в питоне нужно больше думать о проверках в runtime, что удлиняет и усложняет код.

[vada]

Ничего странного - БД это прежде всего корпоративный сектор, а OpenSource (массовый) - это в основном всякие мелкие свистелки и хотелки. Не вспомню с ходу ни одного серьезного приложения Enterprise-уровня, реализованного в чистом OpenSource.

JBoss очень себе даже корпоративный сектор. Да вообще почти все что связано с java исходники открыты. А java это как раз корпоративный сектор.

А вообще по топику - религиозные войны.

2 PascalBeginer вброс удался

[leo_bsv]

2 PascalBeginer вброс удался

+1
p.s. всё это рок-н-ролл

[debi12345]

def myfunc():
return 'qwe'

a, b, c = myfunc()

for i, v in enumerate(myfunc()):
print '%d:%s'%(i, v) # 0:q 1:w 2:e
=================
Да, очень удобные фишки. Тем не менее уже месяц волком вою, перелолпачивая большой проект на скриптовом языке (TCL = вариант Пайфона с другим синтексисом).
Скажу честно, основная проблема - нет проверки ошибок на этапе компиляции. Для мало-мальки серьезноего пректв с несколькоми вызывающими друг друга формами - это смерть.
Например, чтобы отловить тупейшую ошибку в спеллинге (обычное дело - особенно при различении регистров), каждый раз приходится проходить через пол-программы. Такая тупая трата времени, что ее не скомпенсируют никакие супрфишки и никакая самая крутая библиотека Если до вчера-сегодня еещ были смомения на чем писать новый огромный проект ( приятели сколоняли к Пайфону ) - то теперь млын никакого Пайфона с моим участием ! Рогами упрусь, буду угрожать уволиться - но кошмар последнего месяца не должен повториться.

[FedeX]

>Скажу честно, основная проблема - нет проверки ошибок на этапе компиляции.

Тоже испытываю сейчас проблемы с этим, хотя и не слишком большие - текущий проект phonegap-приложение на чистом JavaScript и HTML, мобильный клиент для одного твиттер-подобного сервиса. Более десяти форм уже со списками, работой с SQLite, графиками, кешированием, много сетевого взаимодействия. Но благодаря четкому ООП (хоть оно и костыльное в жаваскрипте), неймспейсам, использованию паттерна MVC, и неиспользованию никаких фишек, вроде кодогенерации или передачи данных через глобальные обьекты, если где и обьявляется рунтайм ошибка, она не уходит далеко от места своего возникнования и легко отлавливается в дебагере.. Еслиб не сложноуловимые баги и особенности вебкита на некоторых мобильных девайсах и вообще тормознутость программ на яваскрипте под андроидом, блекберри и винфоном, сказал бы даже что мне понравилось писать на JavaScript-e.

[debi12345]

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