The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: What bindings in general need is:
by Richard Dale on Monday 20/Sep/2004, @01:18
|
My hope is that apps will spring up like mushrooms all over. Developing KDE applications with Korundum is so easy it feels like cheating.
There are certainly several good apps using PyQt/PyKDE out there. For instance, the TreeLine outliner, Eric IDE and an interesting sounding app called One Finger are all written in PyQt. I hope now that PyKDE is in the kdebindings cvs and part of every release along with ruby, it will help start to change people's perception of KDE being a C++ centric development environment.
I believe C# and java are systems programming languages, which are more of a tidied up version of C++ than RAD languages. There isn't anything wrong with them, but they just aren't the same thing as python or ruby. That's why java has been successful on the server and a complete flop on the client, simply because server side programming needs systems programming languages and the client needs more dynamic RAD languages. Objective-C is a very dynamic language, which is why Apple's Cocoa development environment works so well. It couldn't be implemented using java, and although there are java bindings they don't get used much.
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Philippe Fremy on Monday 20/Sep/2004, @04:05
|
> Developing KDE applications with Korundum is so easy it feels like cheating.
That's exactly what I feel when using PyQt. You write the code and you are wondering why it is so simple. Then you just run it and it works. The absence of a compile cycle is a real pleasure because the code works quicker. And languages like python or ruby are easier to manipulate than C++. No ';', no need for parenthesis inside every if/while, no variable type declaration, very few type errors, uniform API. It really feels easier.
I have converted none of my PyQt applications to C++ and I see no reason why I would.
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Richard Dale on Monday 20/Sep/2004, @04:21
|
I love it the way the rubyists and pythonistas seem to be in violent agreement here.. :)
|
[
Reply To This | View ]
|
Pure Lazyness
by Pure Lazyness on Monday 20/Sep/2004, @07:46
|
Python and Ruby may be nice but not enough if you're looking for pure lazyness. To achieve that we'd need Haskell bindings :D
|
[
Reply To This | View ]
|
Re: Pure Lazyness
by gerd on Monday 20/Sep/2004, @07:58
|
what about basic or Delphi?
Most people here celebrate Python and Ruby because they achieve the same what visual Basic and Delphi provided for years.
|
[
Reply To This | View ]
|
Re: Pure Lazyness
by Philippe Fremy on Monday 20/Sep/2004, @08:12
|
You are joking right ? I don't know for Delphi, but Visual Basic has some inner limitations (limited class model and other stuff) that python and ruby do not have.
For example, I sometimes like to do a dynamic class inheritance. I have also seen python used as a functional language, which I doubt Visual Basic could ever do.
|
[
Reply To This | View ]
|
Re: Pure Lazyness
by Richard Dale on Monday 20/Sep/2004, @08:23
|
"they achieve the same what visual Basic and Delphi provided for years"
No, not at all - both python and ruby are a long, long way ahead of what Basic and Delphi provide. Basic started off as a simpified FORTRAN, pascal (ie the Delphi language) started off as a simplified Algol. Ruby and python don't share those ancestors, instead they are more branches off various AI research languages. I started programming in 1976 learning the language POP-11 on an AI course, and of all the languages I've used in the next quarter century ruby is the most similar. Even in the mid-1970s I regarded Basic (and FORTRAN) as an outdated pile of crap and I've always been puzzled as to why Basic subsequently became so popular in the 80's.
Matz the ruby designer isn't familiar with POP-11 as far as I know, and so it is only a coincidence that ruby is similar.
Python and ruby are languages for the 21st century, whereas Basic and pascal are both well past their sell by dates - I personally feel it is time to move on. Blocks, closures, continuations, list processing, pattern matching - that's ruby's realm and it used to be the exclusive preserve of AI languages like lisp (or POP-11 based on the lamda calculus like lisp, but with an Algol look).
|
[
Reply To This | View ]
|
Re: Pure Lazyness
by Evan "JabberWokky" E. on Monday 20/Sep/2004, @10:57
|
I've always felt that Delphi was much more closely related to Modula3 (which is related to Pascal, which is related to pseudocode for programming which is arguably related to Algol).
Ruby and Python are certainly "post compiler" languages. They do things in a way that ignores any considerations to the structure of the language compiler or interpreter. Other languages are tied to certain concepts regarding the underlying architecture and mechanics of the processor and machine. There are still some legacy concepts pulled over (hopefully the good ones), but they are very distinct from languages like C or C++... or even proper BASIC.
Incidently, this somewhat supports the idea that C (and derived) languages have their place as the underlying layer - if only to keep out system level extensions that would otherwise constrain a high level language. Use C (and kin) to build up from the processor to get to a level where easy tools can be used. In that sense, KDE and (BSD|Linux|Unix) are basically device drivers for the abstracted language.
|
[
Reply To This | View ]
|
Re: Pure Lazyness
by Richard Dale on Monday 20/Sep/2004, @16:28
|
"I've always felt that Delphi was much more closely related to Modula3 (which is related to Pascal, which is related to pseudocode for programming which is arguably related to Algol)."
If you read up on James Gosling's background you'll find he didn't have any object oriented programming experience before designing java and imposing it on the rest of us. He implemented a uscd-p system pascal compiler system on dec vax to solve some problem he had in the early 80's I believe, and just used that idea in conjunction with knowing the C++ had big problems, to invent java.
I feel Anders Hejlsberg (Delphi/C# designer) has more intellectual horsepower than Gosling, and certainly would have known about Modular-3 when implementing Delphi. Even so, when I attended a Delphi introduction presentation in 1996 or so, I can only remember feeling utterly underwhelmed. I was a fulltime NeXTStep programmer used to the dynamic runtime of Objective-C, and just couldn't understand why a warmed over Object Pascal would appeal to anyone..
|
[
Reply To This | View ]
|
Re: Pure Lazyness
by D on Tuesday 21/Sep/2004, @18:12
|
As opposed to a warmed over Object C? Smalltalkers on the other hand wonder what glue you've both been sniffing.
|
[
Reply To This | View ]
|
Re: Pure Lazyness
by Richard Dale on Tuesday 21/Sep/2004, @18:53
|
Yes, java doesn't seem to have been influenced by Smalltalk because maybe James Gosling didn't know anything much about it. Which is a shame - he wouldn't have come up with static methods instead of proper class methods with dynamic despatch. And classes would have been objects that you send a 'new' message to create an instance. That design error has been carried through to C# - I really don't like static methods.
"Resist the urge to overuse static methods.":
http://www.ftponline.com/javapro/2004_09/magazine/columns/proshop/
|
[
Reply To This | View ]
|
Re: Pure Lazyness
by Evan "JabberWokky" E. on Thursday 23/Sep/2004, @12:44
|
I have a feeling much of the reason is due to Borland's wide set of users that used TurboPascal and ilk to write real apps. Much like a C programmer moves to C derived languages easily, Delphi was easy for somebody used to Borland's Pascal offerings.
Incidently, Objective-C was specifically the reason I kept referring to "C derived languages". I'd love to use it, but haven't had a project that was appropriate. Other than a few single file programs one step beyond "Hello World", I haven't played with it. Most of my time these days is spent with PHP and enforcing proper coding practices on developers with bad habits.
|
[
Reply To This | View ]
|
Re: Pure Lazyness
by Pure Lazyness on Monday 20/Sep/2004, @08:42
|
Well Delphi would not achieve that, Haskell on the other hand is *Purely* functional and uses *Lazy* evaluation :) I was going for a easy harmless joke. Guess it didn't work.
|
[
Reply To This | View ]
|
Re: Pure Lazyness
by Philippe Fremy on Monday 20/Sep/2004, @08:03
|
So, when do you start one ? An OCaml binding would be welcome too. Given that there is a binding generator for already a few languages (Java, C#, ruby and perl if I am correct), it should not be that hard to add a few more.
|
[
Reply To This | View ]
|
Re: Pure Lazyness
by Richard Dale on Tuesday 21/Sep/2004, @18:57
|
Ashley Winters, the guy who designed the Smoke library did start on an OCaml binding. I don't know how far he got with it.
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by juanjo on Monday 20/Sep/2004, @12:52
|
I for one, having working for an entire year on a big commercial proyect 80% done in Python would welcome optional variable type declaration. Yes, pychecker helps a lot to catch sintantic errors that a compiler would catch in C++ (and a lot of other errors) or using not previously (auto)created vars and things like that, but it just can't catch:
var = 50
[...some hundreds locs here...]
vra = var + 1 # You'r fscked here
or...
myReallyMustBeAList = [var1, var2, 34]
[...bla...]
# Woop! I really mean to do "someOtherList.append(34)" but
# I've been working for 12 hours, you know...
someOtherList = 34 # Now someOtherList is an Int
myReallyMustBeAList = someOtherList
myReallyMustBeAList[4] # Fscked up you are!
I think Python 2.4 will allow you to declare the types of accepted/returned vars of functions and methods (using new python decorators); it's a start, but I would love to have _an option_ to enforce type declarations to avoid these kind of stupid but sometimes very hard to catch errors; it would help a lot in managing big proyects like mine. ¿Do you need some auto-declared var to do some dynamic magic or a function/method to act as a template? Just don't declare it (95% of vars aren't like these anyway). Declaring the type of vars, and not allowing them to change without explicit conversion, would also allow for some agresive optimizations, too.
On the other side, I love python, it's incredibly productive, the sintax is very clear and the libs are awesome.
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Philippe Fremy on Monday 20/Sep/2004, @13:26
|
I agree 100%. For every big python project, the dynamic typing becomes a problem. I enforce type arguments on all my functions but that's clearly not enough.
Actually, there are very few circumstances where I would change the type of my variable dynamically. I consider that bad programming style. So a static typing system would be ok and certainly remove lot of problems.
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Corbin on Monday 20/Sep/2004, @14:06
|
What about at like the start of the Python script you some way declare that all variables must be declared. And then create a new 'dynamic' type so in case you want some variable to still be dynamic and all it could be. Also if in the start it isn't declared that all variables must be declared, it acts like it does now.
That way everyone wins! I think...
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Philippe Fremy on Monday 20/Sep/2004, @14:16
|
Well, say that go Guido ! Next time I'll interview him, I'll ask for sure :-)
(shameless plug: http://www.freehackers.org/fosdem2002/guido.html)
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Rayiner Hashem on Monday 20/Sep/2004, @17:14
|
That's not unlike what soft-typing languages do. In those languages (Common Lisp, many Schemes, Dylan), a type declaration is an optional constraint. If you put it in, it can help the compiler optimize the code, and check for errors. If you leave t out, you can still use full dynamicity. The usual development style with such languages is you write your "prototype" in a fully-dynamic, general manner, and then gradually convert that into your production code by adding declarations, refactoring, and optimizing.
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Shulai on Monday 20/Sep/2004, @18:26
|
That's in my list of reasons I not really like python.
Also you can count the sloppy OO style, and even the tabbed blocks, even admitting it is nice to force people to write cleaner code).
I like more Pike, sadly it is soooo unknown and underused...
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Ochoto on Monday 20/Sep/2004, @15:28
|
<BLOCKQUOTE>
"That is to say, if a program compiles in a strong, statically typed language, it just means that it has passed some tests. It means that the syntax is guaranteed to be correct (Python checks syntax at compile time, as well. It just doesn't have as many syntax contraints). But there's no guarantee of correctness just because the compiler passes your code. If your code seems to run, that's also no guarantee of correctness.
The only guarantee of correctness, regardless of whether your language is strongly or weakly typed, is whether it passes all the tests that define the correctness of your program."
</BLOCKQUOTE>
<a href="http://www.mindview.net/WebLog/log-0025">Bruce Eckel</a>
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Jonas B. on Tuesday 21/Sep/2004, @02:19
|
Oh, you mean what Perl solved with 'use Strict'. Sorry, I couldn't help myself.. :) One other thing that could actually help which isn't really what you're looking for is design-by-contract. I believe Python has some implementation of it, but I've only played with the Perl one. It's a little bit invasive, but can solve errors similar to type errors in the dynamic language realm. Check it out, you might like it ...
|
[
Reply To This | View ]
|
|
Re: What bindings in general need is:
by Phil Thompson on Monday 20/Sep/2004, @02:37
|
That's the commonly held view but I think it is (mostly) wrong. Scripting languages are certainly good for prototypes and quick apps, but in my experience with PyQt I can't recall anybody converting to C++ later on. They might have started a project with that intention, but soon realise that there is no point.
I see the Python/Ruby vs. C++ issue as being the same as the C vs. assembler issue 25 years ago - when you look back on it in a few years time you'll wonder how you managed to write anything useful in C++.
Richard's point is exactly right. Hopefully the increased exposure of alternative Qt language bindings will help challenge current perceptions. I'm aware of many more commercial PyQt applications than open source applications. The driver in the commercial world is programmer productivity/cost rather than any perceived architectual advantages or disadvantages.
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Evan "JabberWokky" E. on Monday 20/Sep/2004, @05:05
|
I *know* I have read of such a project very recently. Scribus, perhaps?
It is rare, however.
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Henning on Monday 20/Sep/2004, @06:37
|
Only the first versions of Scribus were written in PyQt.
But the text rendering was to slow and it was rewritten in C++.
Perhaps it would have been better to replace only certain
widgets with C++.
But now there is still a possibility for scripting Scribus with Python
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Roberto Alsina on Monday 20/Sep/2004, @06:52
|
If only Pyrex worked well with C++ you could write those pieces in almost-python and get almost-C++ speeds :-P
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Humberto Massa on Monday 20/Sep/2004, @11:44
|
Why doesn't pyrex work well with c++? Why does it not work with PyKDE/PyQt?
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Roberto Alsina on Monday 20/Sep/2004, @11:58
|
Quoting the Pyrex docs:
-----
Future Plans
C++ support. This could be a very big can of worms - careful thought required before going there.
------
And it doesn't work well with PyQt/PyKDE because there is no simple way to pass a C++ object to a Pyrex extension and use it from Pyrex.
Sure, you could use Pyrex for code that only needs to use integers and floats, but how much code like that is in your average Qt application?
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Phil Thompson on Monday 20/Sep/2004, @10:23
|
Replacing certain widgets with C++ versions would have been my suggestion. This is similar to what was done with eric (the PyQt IDE). The quickest way to add a good programmer's editor was to port Scintilla to Qt, produce Python bindings for it, and write the rest of the IDE in Python.
Another common approach of commercial users when they want to revamp an existing C++ application is to isolate the core functionality in a library (if it's not already structured as such), produce Python bindings for it, and rewrite everything else (particularly the GUI) using PyQt.
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Philippe Fremy on Monday 20/Sep/2004, @13:24
|
Yep. It is exactly what I am doing at the moment for my job. We have a little C++ library that does some of the irreplacable system code. We wrap it with boost and use python everywhere else. It is a _very_ productive language. I also love the way I can quickly write complicated tests or the way I can make arguments expclicit:
Compare:
acs = generate_acs( ACS_ALWAYS, (ACS_AUTH, KEY_1), ACS_NEVER, ACS_NEVER )
CreateFile( 300, 0x3F00, acs )
with:
acs = generate_acs( read=ACS_ALWAYS, write=(ACS_AUTH, KEY_1),delete=ACS_NEVER )
CreateFile( size=300, id=0x3F00, access=acs )
|
[
Reply To This | View ]
|
|
Re: What bindings in general need is:
by Brandybuck on Monday 20/Sep/2004, @11:27
|
I think there are two "hurts" for bindings. Depending on your perspective they could be major, minor or trivial hurts, but I have tripped and bashed my knee on them in the past. The first is that you limit your pool of maintainers and code contributors. I don't know Ruby, so I can't help with a project written in Ruby without first learning the language. The second is that you imposing additional software (vm's, interpreters, runtime libs, etc) on the user.
The last thing I want to do is to discourage anyone from coding in any non-C/C++ language. But these language do come at a price and we should be aware of them so that we can balance those costs with the costs of using C/C++.
|
[
Reply To This | View ]
|
Re: What bindings in general need is:
by Boudewijn Rempt on Monday 20/Sep/2004, @12:08
|
The extra runtime requirements used to be a much bigger problem than it is nowadays. In the early days of PyQt you really couldn't ask ordinary users to try to install PyQt themselves. I was constantly helping prospective users of Kura, my language description software, to install Python, Qt, PyQt and everything in the right order. Nowadays, most distributions package a useful version of PyQt, and there are far fewer problems.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
