How would you improve Python? I want to picture the perfect practical, multi-paradigm language. I decided to start with Python because I think it's the easiest one to fix. Lua would be another good candidate. So this is what I'd do to Python:
- def and class become expressions and specifying a function class or name is optional. They still maintain the forced indentation of code, and can be used as follows: function = def (x, y): #Indentation level = 0
x + y #Indentation level = 4, inside the def
print... #Indentation back to 0, thus def ended, and assignment ended
tuple_of_functions = (def (x, y): #Indentation level = 0
x + y #Indentation level = 4, inside the def
, lambda x: -x) #Indentation back to 0, thus def ended, assignment did not because of parens
(Note that you can wrap def and class around extra parens to use like braces if you don't like that comma there.)
- $ becomes shorthand notation for lambda, so $x: x + 1 is the same as lambda x: x + 1 . Furthermore, ${ ... } becomes a shorthand for def ():, and supports nested braces, e.g.: f = ${
x = 0 #The forced indentation of code begins at whatever column the contents of ${ start
if x:
do_something(${ ... })
}, 1, 2, 3, ${ ... } #f is a tuple of <lambda>, 1, 2, 3, <lambda>
The closing brace may appear anywhere. If you start the contents of ${} in the same line, as in ${ x + 1 }, you are limited to a single line.
- Besides the forced indentation of code, there's the forced tail call optimization in the language specification, so any interpreter must do it.
- if, while, for, with and try become expressions which return the latest expression they evaluated, and can be used anywhere. A def function returns the last expression evaluated, so the return keyword is optional when specified at the end of a function. break and continue become (special) expressions that return nothing and are only valid within while. print, import, exec and assert become functions. raise becomes a expression. del, return and yield become special expressions. global becomes an expression but it'll be deprecated. pass is deprecated, and becomes a synonym of None. Assignment statements will disappear in a later suggestion. Thus no statements remain. Introducing the forced expressions.
- New while-like expression: do: (forced indentation of code) ... (dedent) while condition (like C's do { } while ();)
- Assignment operations return the assigned value, as in C.
- ++ and -- operators, as in C. They call methods __inc__() and __dec__(), and return the original or the modified value depending on whether they appear before or after the variable.
- Incompatible change: if you assign to a variable in some way (like using = or def), you create a new variable in the local function, as you do in Python, but only if this variable doesn't exist in an outer lexical scope. If it does, then the outer variable is modified. To specify the forced creation of a local variable with the same symbol as an outer lexical scope, you use the local special expression, prefixing the variable name with "local" anywhere in the function, e.g.:
[code]def f():
i, j = 1, 1
(def ():
i, local j = 2, 2
#local j++ would have caused an exception, as j did not exist and ++ requires that it exists, like j += 1
)()
print i, j #Expected: 2, 1
- Braces quote strings like Perl's q{} operator. They can be nested, so {a{b}} is the same string as 'a{b}'.
- .. is a new operator. Used with ints, it generates xrange objects, e.g. 3..10 returns xrange(3, 11). Used with other objects, it calls __range__(other) or __rrange__(other).
- All the changes coming in Python 3000 regarding dictionary functions, deprecated functions, etc. should be applied too.
So, what do you think? Did I screw up somewhere? These changes would allow better functional programming with Python, and something close to macros or TCL commands, e.g. you could define an iff(c, t, f) macro which doesn't evaluate both t and f like: def iff(c, t, f):
t() if c() or f()
Assignment would work, there's multiline ${}, etc.
Name:
Anonymous2007-07-09 13:40 ID:EMMQaZLB
as long as forced indentation stays, python is synonymous with failure
Name:
Anonymous2007-07-09 13:42 ID:VAM8zb9e
>>1
ONE WORD, THE FORCED INDENTATION FO THE CODE, THREAD OVER!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Name:
Anonymous2007-07-09 18:51 ID:nPmYkd1e
>>1
Failed at BBCode and didn't even realize. Fixing.
How would you improve Python? I want to picture the perfect practical, multi-paradigm language. I decided to start with Python because I think it's the easiest one to fix. Lua would be another good candidate. So this is what I'd do to Python:
- def and class become expressions and specifying a function class or name is optional. They still maintain the forced indentation of code, and can be used as follows: function = def (x, y): #Indentation level = 0
x + y #Indentation level = 4, inside the def
print... #Indentation back to 0, thus def ended, and assignment ended
tuple_of_functions = (def (x, y): #Indentation level = 0
x + y #Indentation level = 4, inside the def
, lambda x: -x) #Indentation back to 0, thus def ended, assignment did not because of parens
(Note that you can wrap def and class around extra parens to use like braces if you don't like that comma there.)
- $ becomes shorthand notation for lambda, so $x: x + 1 is the same as lambda x: x + 1 . Furthermore, ${ ... } becomes a shorthand for def ():, and supports nested braces, e.g.: f = ${
x = 0 #The forced indentation of code begins at whatever column the contents of ${ start
if x:
do_something(${ ... })
}, 1, 2, 3, ${ ... } #f is a tuple of <lambda>, 1, 2, 3, <lambda>
The closing brace may appear anywhere. If you start the contents of ${} in the same line, as in ${ x + 1 }, you are limited to a single line.
- Besides the forced indentation of code, there's the forced tail call optimization in the language specification, so any interpreter must do it.
- if, while, for, with and try become expressions which return the latest expression they evaluated, and can be used anywhere. A def function returns the last expression evaluated, so the return keyword is optional when specified at the end of a function. break and continue become (special) expressions that return nothing and are only valid within while. print, import, exec and assert become functions. raise becomes a expression. del, return and yield become special expressions. global becomes an expression but it'll be deprecated. pass is deprecated, and becomes a synonym of None. Assignment statements will disappear in a later suggestion. Thus no statements remain. Introducing the forced expressions.
- New while-like expression: do: (forced indentation of code) ... (dedent) while condition (like C's do { } while ();)
- Assignment operations return the assigned value, as in C.
- ++ and -- operators, as in C. They call methods __inc__() and __dec__(), and return the original or the modified value depending on whether they appear before or after the variable.
- Incompatible change: if you assign to a variable in some way (like using = or def), you create a new variable in the local function, as you do in Python, but only if this variable doesn't exist in an outer lexical scope. If it does, then the outer variable is modified. To specify the forced creation of a local variable with the same symbol as an outer lexical scope, you use the local special expression, prefixing the variable name with "local" anywhere in the function, e.g.: def f():
i, j = 1, 1
(def ():
i, local j = 2, 2
#local j++ would have caused an exception, as j did not exist and ++ requires that it exists, like j += 1
)()
print i, j #Expected: 2, 1
- Braces quote strings like Perl's q{} operator. They can be nested, so {a{b}} is the same string as 'a{b}'.
- .. is a new operator. Used with ints, it generates xrange objects, e.g. 3..10 returns xrange(3, 11). Used with other objects, it calls __range__(other) or __rrange__(other).
- All the changes coming in Python 3000 regarding dictionary functions, deprecated functions, etc. should be applied too.
So, what do you think? Did I screw up somewhere? These changes would allow better functional programming with Python, and something close to macros or TCL commands, e.g. you could define an iff(c, t, f) macro which doesn't evaluate both t and f like: def iff(c, t, f):
t() if c() or f()
Assignment would work, there's multiline ${}, etc.
Name:
Anonymous2007-07-09 20:38 ID:wvK7BwWv
from __future__ import braces
Name:
Anonymous2007-07-09 21:13 ID:+8E8UF+D
all python needs is defmacro. then, just write a codewalker.
or just write a really really really good python-CL interface, and let's use python libraries.
How would I improve Python? I would drop everything that makes Python Python and declare Haskell the new Python; Haskell being the perfect [multi-paradigm] language.
Name:
Anonymous2007-07-10 15:20 ID:+x2F+S1V
>>12 HASKELL IS SINGLE PARADAIGM
CONSIDER THIS MY FRIEND,
1) IMPLEMENT A PROGRAM WHICH MUTLIPLIES 2 MATRICES TOGETHER (IN HASKELL)
matmult a b = map (\v -> map (dot v) (transpose b)) a
Name:
Anonymous2007-07-11 4:08 ID:L/E3ZLA2
>>15
- XBOX amount of features which make people use just a subset, only that your subset is not the same subset as the next guy's, etc.
- Stupid typing
- Template insanity, created to workaround the static typing flaw
- Weird standard library (<< and >> on streams?)
- Suboptimal class definition syntax
- Lack of interesting features (e.g. lexical closures)
- Surely more features is better? I would rather program in C++ than in Brainfuck, and so would you.
- Hardly insanity, works well. It is a workaround that works.
- Purely subjective, I happen to think it is very nice.
- Suboptimal != broken.
- > XBOX amount of features
> Lack of interesting features
Good job being a hypocrite.
Name:
Anonymous2007-07-11 8:31 ID:ICuj0l5P
stupid typing
You shouldn't be blaming your poor keyboard operating skills on a programming language.
>>18 Surely more features is better?
Who told you that? Features are not universal good of which you have to get the most. You need the smallest set of the most useful features that will accomplish a job efficiently. For example, since you have = to assign values, you don't need ten other ways to do it, even though they would be features.
- Hardly insanity, works well. It is a workaround that works.
Nested templates are insane, and an ugly workaround.
Lack of interesting features
Of course. I want few, useful features, such as closures, first-class functions and classes, simple introspection, proper tail calls by specification, etc.
>>19
I hope you are joking. But on /prog you can never tell.
Name:
Anonymous2007-07-11 9:31 ID:7OyMukUl
closures can be sort of emulated using `functors' (ie. overloading the () operator of an object)
Name:
Anonymous2007-07-11 9:32 ID:7OyMukUl
BTW, check out the Boost Library for interesting features (there's a neat Lambda library in there)
Name:
Anonymous2007-07-11 9:33 ID:jeLF5pF5
Use java
seriously. It is python with real typing.
>>2,>>3
Forced indention is a GOOD THING (tm) because in other languages every fucking tard makes their own indention scheme and when using or reading other peoples code you end up with a horrible mess. Python makes everyones code look similar.
OCaml ftw!
Name:
Anonymous2007-07-11 11:57 ID:L/E3ZLA2
>>22
"Sort of emulated" sounds like a hack that looks like closures but doesn't have any of the actual advantages of them.
>>23
In MY C? How would you do that, without including a compiler in the final executable and compiling in real time? Unless, again, they only look like lambdas, but don't have the actual advantages of them.
>>25 more choice is better
For a one-man project using almost no libraries? Yes.
"Ugly" is purely subjective, once you get used to them it becomes easier on the eye.
Just like Befunge.
There is a lot more stuff in the Boost libraries, and some of this is going to be included in C++0x (whenever the x may be)
Great! Let's bloat it some more!
Designing a good language is not about piling features over features. It's about eliminating the stupid restrictions of your basic features that force you to include more features which make the design big and ugly. A braindamaged base design decision (such as being a static language) is like the butterfly effect: it introduces all sorts of unexpected braindamaged design decisions on anything that's built upon it.
>>27
Interesting; in what ways did I make it ugly?
In this call to sort, we are sorting the elements by their contents in descending order.
sort(vp.begin(), vp.end(), *_1 > *_2);
tell me that isnt cool
Name:
Anonymous2007-07-11 20:24 ID:EW6YBfCj
>>25
May I suggest you use Python a while? I don't like the language much, but you just can't get much worse than C++ (or its close sibling, Java).
>>1
I'm sure there are plenty of good ideas in there, but my eyes just exploded. Consider selling your newfound means of blinding people to the military. :(
Name:
Anonymous2007-07-11 20:57 ID:FcOOn6ET
Sorry, >>11 here. Exactly what are the features of Python that aren't as nicely supported (or supported at all) in C++? I won't learn Python just to participate in this discussion, so you have to be crystal clear (not just 'interesting features'). Give example syntax too if it will help.
Name:
Anonymous2007-07-11 21:59 ID:HXCM686m
>>32
you can pick up python in a day. I don't even know python, but for a simple start...
nested procedures, first class functions (functors are a nice but ugly workaround, same as boost lambda and CLAMP), metaclasses. of course it does not have templates, but it does not need to.
Name:
Anonymous2007-07-11 23:37 ID:FcOOn6ET
Again though, I'm not gonna download python compilers, search for good learning sites, and spend a day learning just to take part in this discussion. All I want to know are the features that Python supports that C++ doesn't. I don't care about ugly vs nice syntax for this discussion. I'm talking about whether it is a feature of the language without having to resort to Turning completeness.
I understand first class functions and I understand that C++ doesn't support them. So that's a good example. (Personally though, passing and returning function pointers are all I've ever needed, and those are fully supported by C++).
So what are nested procedures and metaclasses?
Name:
Anonymous2007-07-11 23:56 ID:HmkKUBs1
This is hilarious.
It's not a question of what Python supports that C++ doesn't. Thanks to the power of libraries you can make C++ (or any other language) do a backflip and eat apple pie. Wow, look at that!
The question is, how much effort does it take to do achieve it?
>>The question is, how much effort does it take to do achieve it?
Yes.
>>It's not a question of what Python supports that C++ doesn't.
But aside from easier to use syntax that *is* what it boils down to. If you can only do something with a library how does that imply it takes much more effort? It doesn't. Including a library instead of having that library available by default does not take effort.
If, however, you can only do something by subverting the language and resorting to Turing completeness then, yes, you have genuinely lost something. You've basically changed the language to make that happen, and so it's irrelevant when compare the languages (which in this case is C++ vs Python).
I'm not trying to defend C++. I asked for "just the features" because I don't want you defending Python. "just the features" may not be the complete story, but it certainly eliminates a lot of the noise.
Name:
Anonymous2007-07-12 1:29 ID:xJoFadi8
But aside from easier to use syntax that *is* what it boils down to.
I disagree. With a language like Lisp where operators are just as malleable as words (they're all just symbols after all), you'd be right. Add a library, et voila! But C++ isn't Lisp.
The reason C++ has become a land of template-based boilerplate magic is exactly because syntax isn't what it boils down to. I'd like to see C++ pull a strongly-typed duck typing system out of its hat. If it can be done, I expect to see an explosion of chevrons.
As an aside: it's for this reason that I don't understand why Lisp seems stuck in the stone-age (hello Common Lisp!). They're all too busy wanking over their superiority to come up with a single canonical distro with a modern "batteries included" standard library.
Name:
Anonymous2007-07-12 2:39 ID:OICFNFAi
I don't think we disagree. Static typing is feature of the C++ language. Duck typing is a feature of Python. Further, duck typing cannot be added to C++ with a library. And if you could it'd be full of shit like you said. So duck typing is a good example of a feature that C++ doesn't have. That's all I'm asking for. If you insist, it doesn't have to be a perfectly well defined line either.
I just don't want to listen to shit that is pure opinion.
Exactly what are the features of Python that aren't as nicely supported (or supported at all) in C++?
Too many to tell, here are just a few examples with Python code:
def CreateAdder(x): #Define a function
return lambda y: x + y
#The above lambda expression creates an anonymous closure.
#It's a function which can access variables in outer scopes,
#and it doesn't have a name because it's an expression, so
#you either assign it somewhere or pass it somewhere.
#It's a function of y, which returns the addition of x
#(CreateAdder's parameter) and y (its own parameter).
#Note that the function we build is different every time,
#it depends on how you call CreateAdder.
inc = CreateAdder(1) #We bind the result of CreateAdder(1) to a variable.
#But wait, did we really said this works with integers? NO!
#This does "+". "+" operates on anything that supports "+".
#ANY function or class is a template. And so far, I haven't
#wasted one second defining or specifying any data type anywhere.
#"+" is actually syntactic sugar for a method call.
#When we do object1 + object2, we're just doing
#object1.__add__(object2), so if object1 defines its __add__ and
#its __add__ knows how to add object2, whatever that is, then it works.
#See how the str class also has an __add__ method. 'a' + 'b' is the same
#as 'a'.__add__('b'). But is __add__ a method? Yes, of course, but methods
#are no different than functions. str is the class holding the method,
#which is a function which receives its object and other parameters, so
#it would be the same to do str.__add__('a', 'b').
#We can concatenate lists
my_list = my_list + my_list
#What if we compare them?
print my_list == my_list
#This prints True, not because they are the same reference, but because
#each of their values is equal when using == (which is just method __eq__)
#For reference comparison, we can use my_list is my_list
#And we can use list comprehensions to define a list we want to obtain:
[x * 10 for x in xrange(100)]
#We're building a list of x multiplied by 10 for all x in 0..99
#But that's too easy. Let's do something better:
[[x, y] for x in xrange(100) for y in xrange(100) if x < y]
#Ok. Now we obtain a list of lists [x, y] for all x in 0..99 and y in 0..99
#if x is lesser than y, so we obtain [[0, 1], [0, 2], ..., [7, 9], [8, 9]].
#Back to a simpler list...
my_list = [i[0] + i[1] for i in my_list] #We sum the couples of above
#Let's obtain a list that's the result of applying inc
#(our CreateAdder(1) function) to each of my_list elements.
#Would you waste your time iterating manually over it? No!
results = map(inc, my_list)
#Ok, so now we want to add all of the elements of my_list, applying a
#function to the accumulated result and the next list item successively
sum = reduce(int.__add__, my_list)
#Wait, that calls int's __add__. We want to add anything. Let's call a
#generic __add__
import operator as op #Somewhat like #include <operator>
sum = reduce(op.__add__, my_list)
#We could also define our own generic add function, like:
#sum = reduce(lambda x, y: x + y, my_list) #Same as op.__add__
#Now that's much better. The reduce works with any class that happens
#to implement __add__.
#By doing this, we obscured the sum() builtin which already does this
#reduction for us. We want to use sum again.
del sum #Delete our sum; now sum does not exist and a builtin is looked for
#Ok. Did you know about dictionaries? They are hash tables.
for key in d: #Iterate over the dictionary
print 'd[', key, '] = ', d[key]
#We can use keyword arguments for functions.
def lots_of_options(a=1, b=2, c=3, d=4, e=5):
#5 parameters, with default values
print a, b, c, d, e
lots_of_functions(c=100) #Just set c, use defaults for the rest
#With keyword arguments we don't need to remember their order
#We can also receive any arguments
def show_me(*args, **kwargs):
print "I've received these unnamed arguments:"
print args
print "and these dictionary arguments:"
print kwargs #kwargs is a dictionary
#We can also apply functions to lists or dictionaries so easily.
params = [1, 2, 3]
#Now my_function(1, 2, 3) could be called like my_function(*params)
#Now let's play with generators/coroutines.
def generator():
#This is a function which returns values but remains active, with
#its instruction pointer and local variables.
a = 5
yield a #Yield 5
a = a + 1
yield a #Yield 6
g = generator() #We use the g object to obtain its results
print g.next() #5
print g.next() #6
print g.next() #Raises StopIteration exception
#Now let's do some classes.
class C(object):
'''This is a docstring. You can document Python code in a
standard way, with introspection. You can obtain this string
from Python itself. No external tools necessary.'''
def lol(self): #Define a method
'''Docstring'''
#Methods receive the bound object ("this") by parameter
print 'In lol'
class D(object):
#We can override the default constructor
def __init__(self, with_lol=False):
#If this object is created with the with_lol option, we
#inherit method lol from C
if with_lol:
self.lol = C.lol
>>35 Thanks to the power of libraries you can make C++ (or any other language) do a backflip and eat apple pie.
So, can you make C++ do dynamic typing, first-class functions and classes, generators, list comprehensions, etc.? Yes, in fact you can. That library is called Python. You can embed Python in C (or C++) to do that.
>>37 As an aside: it's for this reason that I don't understand why Lisp seems stuck in the stone-age (hello Common Lisp!). They're all too busy wanking over their superiority to come up with a single canonical distro with a modern "batteries included" standard library.
Fucking truth. I'd also clean all the legacies Common Lisp has, and that 2-Lisp stupidity. Basically, I'd do what you say but start with Scheme, or even a clean Scheme, plus an awesome macro system and syntax for indexing arrays and dictionaries.
>>38
Ok, I'll try enumerating some features of Python that C doesn't have.
- Dynamic typing (AKA duck typing) with strict types
- Ubiquitous polymorphism (method calls are evaluated in real time, if a method with that name exists it's called, don't give a shit about classes)
- Garbage collection
- Built-in, real, properly defined Unicode support
- Built-in lists (and tuples, read-only lists)
- Built-in dictionaries (hash tables) which can use any immutable key (even tuples!)
- Built-in sets with set operations
- Powerful list slicing (like [a:b:c], to access elements from [a to b) step c)
- List comprehensions
- Functional programming tools
- First-class functions
- First-class classes
- Properties that look and feel like properties but are actually functions: forget that getter and setter faggotry
- Metaclasses
- Functions and classes are closures
- Anonymous functions/closures (AKA lambda expressions)
- Functions can return more than one value (tuples)
- Generators
- Coroutines
- Keyword arguments
- Function application with lists and dictionaries
- Introspection, giving access to object and types dictionaries, backtraces (tracebacks), stack frames, variable dictionaries and debugging facilities, all from the language
- Fully dynamic: *anything* you can do on write-time you can do on run-time, including defining new functions, classes, inheritance rules (mixins), etc., and you can also redefine functions to change or hot-upgrade a program's behaviour without restart
- Dynamic code evaluation: eval and exec execute Python code that's in a string
- Direct access to bytecode and AST editing (though it's fugly)
And I'm probably missing 10-15 awesome features C++ lacks.
If I were you, after reading all of these features C++ can't even dream of I'd start learning Python right now. You can do it in 2 days, then discover how to use all of this with experience as you use it here and there.
Seriously get over yourselves. Dynamic languages are nothing more than executable hash tables. Yes they're generally preferable to languages such as C++ and Java but that's due largely to the godawful design of said languages, not the fact that they don't go out of their way to look up every symbol at runtime.
It certainly shares some features with D, but unlike D is also backwards compatible with earlier C standards. (Most notably, D doesn't have a preprocessor.)
Dynamic languages are nothing more than executable hash tables.
And this is why they are so good/powerful/flexible/introspective. Lists and dictionaries are like violence. If they don't work, use more.
Also, answer how you would do all of what I said in >>43.
>>53
long fucking names (java.classes.forms.blablabla), no manual memory management, it's VERY platform dependent (needs a precompiled runtime) and ITS FUCKING SLOW.
Name:
Anonymous2007-07-13 19:32 ID:0Tapqcf2
no manual memory management
That's a good thing!
Java's problem is that it's a low-level language trying to be high level. Since it's low-level, the productivity sucks. Since it's trying to be high-level (aka hello VM) it's no good at low-level tasks either.