which one do you prefer? python with C# or java?

[Tim Johnson]

If you don't know C yet, I second recommendation to learn it. It is a very
70-tish and 80-tish language, but it is still very relevant if you want to
call yourself a programmer (rather than a hobbyist, with all credits due
to clever genius hobbyists out there). There are things I would rather do
in C than in any other language (like, writing a Python interpreter or
Linux kernel - wait, what you say they have been written already?). Also,
it gives one a way to handtune the code quite a lot (at expense of time,
but this is sometimes acceptable), to the point where next choice is
assembly (and results not necessarily better)...

Later on, since C and C++ share quite a bit, you can gradually include C++
elements into your code, thus writing in a kinda "bettered C" (compiled
with C++ compiler), using constructs like "const" to make your programs
more correct. And you will learn to not use "new" for variables, which is
good thing. However, some C++ constructs include performance penalty, so
it is good to not better it too much.

I concur, I worked in C and C++ for 12 years. I added C++ later in
my programming life. I don't recommend C++ for single programmers.
- that is to say - 1 coder for 1 codebase. One can do good enough
OOP in ansi C believe it or not, I learned to.

It is interesting to note that most of linux is written in C,
rather than C++ and is not python as well?

- Common Lisp - "nice industrial standard" (depends on one's preferred
definition of "nice", of course, as well as "industrial" and "standard")

I took a hard look at Common Lisp at one time. I got the
impression that the "Common Lisp" is not to Lisp what Ansi C is to
C.

IOWS, there does remain incompatibilities between different
Common Lisp implementations.

Whereas Ansi C is pretty strict as code portability (or was so
when I was working in it)

 

[rusi]

I have written about that later ... no, I am a native Czech, but I have
passive Russian, and active English. But there is a difference ... I can
read and enjoy beautiful texts in Russian or English (couple of months
read Eugen Onegin in Russian and that's just a beauty! or C.S.Lewis ...
oh my!) but I will never be able to write professionally in these
languages. I can write (as evidenced by this message) somehow in
English, but I cannot imagine that I would be ever professional art
writer or (even worse) poet. I could imagine (if spent couple of
thousands of days working on it) that I would be a Czech professional
writer though.

Matěj

If we were back-translate that standard to the programming field it
would go something like:
"You cannot call yourself a programmer until you create something of
significance.
So Linus writing the linux kernel or Knuth writing Tex or Stallman
writing emacs, GvR writing Python are programmers; the rest not."

Believe me your English is good enough and better than some mono-
lingual ranters on this list who cannot write 2 straight correct
sentences yet take it upon themselves to correct others' English.

[Sorry for pontificating. I am nearing 50 and have wasted too much of
my life in the misguided pursuit of perfectionism. I would wish for
younger folks to not err samely]

To come back to the OP's question, Alan Perlis said:
A language that doesn't affect the way you think about programming, is
not worth knowing.
More gems here: http://en.wikiquote.org/wiki/Alan_Perlis

If you use this to choose what language to learn, you cant go wrong.
Most programmers who know dozens of programming languages really know
only one imperative language iced with different syntax. Which
reminds me of another quip by Alan Perlis:

Syntactic sugar causes cancer of the semicolon.

 

[Tomasz Rola]

I concur, I worked in C and C++ for 12 years. I added C++ later in
my programming life. I don't recommend C++ for single programmers.
- that is to say - 1 coder for 1 codebase. One can do good enough
OOP in ansi C believe it or not, I learned to.

It is interesting to note that most of linux is written in C,
rather than C++ and is not python as well?

You are right, I remember this was explicitly stated somewhere on usenet
that Linux kernel was written in object oriented style and AFAIK this is
true (based on my own lurking into the source).

But I think C++ could and should be used by solo programmers. I just
suspect once we get past trivial stuff (defining class hierarchies, using
iostreams, containers and STL and the like), things get a little tricky
but I cannot say for sure because I am yet to go there.

I probably agree C++ should not be used by solo progs writing very big
programs, if this is what you mean. I am still researching alternatives,
but for such endeavour I would rather choose Haskell or CL.

However, I notice, for example, Boost C++ Library and their attempt to
recreate some aspects of functional language. This gives me idea about
what can be done in C++ - basically, the stuff is so powerfull it seems to
almost reach into CL-reserved realms. With limitations, because it's
different language, but still impressive for me.

http://en.wikipedia.org/wiki/Boost_(C++_libraries)

http://www.boost.org/doc/libs/1_49_0/?view=category_Function-objects

http://www.boost.org/doc/libs/1_49_0/doc/html/lambda.html

http://www.boost.org/doc/libs/1_49_0/libs/bind/bind.html

OTOH, I guess there are performance penalties. So, it boils down to
individual's decision about pricing his own time or machine's time higher
than another. Like, hand writing specially optimised versions of some
functions or trying to lure compiler into generating them automatically
(with templates).

But, compilers are improving. In algorithmic contests, C++ is used quite a
lot, from what I could see (and some people use Pascal, compile with Free
Pascal Compiler, nice thing).

BTW, Java folks trie(d|s) to go this way (templates etc) too, but I don't
trace their efforts much, so cannot say how they fare(d).

I took a hard look at Common Lisp at one time. I got the
impression that the "Common Lisp" is not to Lisp what Ansi C is to
C.

IOWS, there does remain incompatibilities between different
Common Lisp implementations.

Interesting. I play with CL for some time but haven't rammed this
particular wall yet. Do you remember more about it? If you can't be
specific, perhaps some hint will do.

Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:[email protected] **

 

[Albert van der Horst]

Really, that's only if the new language is pretty much the same as the
old ones, in which case you haven't really learned much of anything.
Languages that use interesting new concepts are challenges in their own
right.

Here is an interesting exercise for statically typed languages,
unsuitable for Python but not too hard in Haskell:

http://blog.tmorris.net/understanding-practical-api-design-static-typing-and-functional-programming/

When I'm satisfied with a program, it has this ethereal property that
if the problem is slightly altered, the program is only slightly
altered. Case in point:going to incorporate the extra 8 register from
64 bit pentium into a pre-existing 32 bit Pentium assembler.
(Which is a in fact a somewhat large messy change that would
trigger a rewrite in most assemblers.)

I much doubt if e.g. the whowonordraw gives a compile time error
on a non-finished board, that the program can be robust against
a small change of the rules. Say strikes going through the lower
left square are not counted as a win.
It is sooo bloody artifical. A normal requirement would be an
API that gives on any tic-tac-toe board one of:
Iwin, youwin, draw, not-finished.

Then there are static typed languages like Forth where the programmer
is the judge whether there is a type error, and type errors are
not generated by the compiler.

A much more natural api is where a board is an object.
You can send a move message -> accepted or nor
You can send an inspect message -> won lost draw or not-finished.

I can make that totally robust without storing lost or draw
information using the type system.

He requires that on several calls, if the data is wrong, you get
a compile time error. How could that be a reasonable demand from
a language like Python where the call can be made interpretively?

Of course it is an exercise. But I think that it went this way:
1. solve it in Haskell
2. require incidental and non-useful features of the solution
to work in other languages the same way.

If he is bashing Scrum, I'm bashing staic typing.

It doesn't require the use of any libraries, standards, style, or
culture. I can tell you as a fairly strong Python programemr who got
interested in Haskell a few years ago, it took me much longer than an
afternoon to get to the point of being able to solve a problem like the
above. It required absorbing new concepts that Python simply does not
contain. But it gave me the ability to do things I couldn't do before.
That's a main reason studying new languages is challenging and
worthwhile.

I give you that. Mastering a functional language is a real
step, but I don't think this tic-tac-toe exercise will entice me to
do that.
Maybe the solutions to http://projecteuler.net that are published
in Haskell sometimes condensing a few pages of my sequential code in
a few lines, will inspire me to take up Haskell.

Groetjes Albert

 

[Paul Rubin]

http://blog.tmorris.net/understanding-practical-api-design-static-typing-and-functional-programming/

When I'm satisfied with a program, it has this ethereal property that
if the problem is slightly altered, the program is only slightly
altered.

One thing I find with Haskell: the type system really seems to help
guide the program towards having that property, by making sure all the
parts fit together cleanly.

Case in point:going to incorporate the extra 8 register from
64 bit pentium into a pre-existing 32 bit Pentium assembler.
(Which is a in fact a somewhat large messy change that would
trigger a rewrite in most assemblers.)

I'd hope that such a change would be easy in a well-designed assembler.

I much doubt if e.g. the whowonordraw gives a compile time error
on a non-finished board, that the program can be robust against
a small change of the rules. Say strikes going through the lower
left square are not counted as a win.

Eh? No, that kind of change is trivial, and wouldn't affect the types
at all. Maybe you're imagining the rules of tic-tac-toe being encoded
in the types, which could in fact be done, especially in fancier systems
like Agda's. But all that we're talking about here is that creation of
values describing game states is reserved to the API implementation by
the module system. The API doesn't export the constructors for values
in the "game state" types. It's just like an OO system that enforces
private instance variables, so that clients can only get at those
variables through accessor functions supplied by the instances.

Then there are static typed languages like Forth where the programmer
is the judge whether there is a type error, and type errors are not
generated by the compiler.

That is not static typing in any normal sense of the term. Forth is
untyped.

A much more natural api is where a board is an object.
You can send a move message -> accepted or nor
You can send an inspect message -> won lost draw or not-finished.

If you attempt a move on a finished board, that is a programming
error. By suffering some extra complexity in the types, you can catch
this particular error at compile time, decreasing your testing
and support burden at runtime. Whether that trade-off is worth it in
practice depends on the problem. For tic-tac-toe it's probably
not worth it except as an exercise, and this tic-tac-toe problem
was in fact presented as an exercise.

I can make that totally robust without storing lost or draw
information using the type system.

I think the exercise simply wanted separate types for complete and
incomplete games, not separate types for win/lose/draw. I could imagine
wanting separate types for wins/losses/draws if there were functions to
award prizes to the winners of games. You'd want to make sure that lost
games didn't get awarded these prizes.

He requires that on several calls, if the data is wrong, you get
a compile time error. How could that be a reasonable demand from
a language like Python where the call can be made interpretively?

You can't, that's the entire point, Python is good for many things but
not for this. So if you want to expand your horizons as a programmer
enough to be able to do this sort of problem, you have to try out more
languages.

Of course it is an exercise. But I think that it went this way:
1. solve it in Haskell
2. require incidental and non-useful features of the solution
to work in other languages the same way.

Not sure what you mean there. The exercise was to use static types to
write an API with certain characteristics. Obviously you can't do that
without static types. It's just like programming exercises involving
writing recursive functions can't be solved in languages like Fortran(?)
that don't support recursion, etc.

And those characteristics (per the specification in the exercise) were
not incidental or non-useful, they were essential.

If he is bashing Scrum, I'm bashing staic typing.

I don't remember what if anything he said about Scrum.

I give you that. Mastering a functional language is a real
step, but I don't think this tic-tac-toe exercise will entice me to
do that.

Functional programming and fancy type systems are separate subjects and
Haskell implements both. Scheme is functional without static types, and
I got interested in Scheme some time before starting to use Haskell.
When I did try out Haskell, I got more from its type system than I
expected to. I thought the following was really cool:

https://gist.github.com/2659812 with discussion at:
http://www.reddit.com/r/haskell/comments/ti5il/redblack_trees_in_haskell_using_gadts_existential/

it implements a data structure (red-black trees) with complicated
invariants that are expressed in the type system in a natural way, so
that the compiler ensures that all manipulations on the trees don't mess
up the invariants.

Maybe the solutions to http://projecteuler.net that are published
in Haskell sometimes condensing a few pages of my sequential code in
a few lines, will inspire me to take up Haskell.

I've done some Euler problems in Haskell but so far, my solutions
haven't used types in particularly interesting ways. Project Euler is
mostly about problems in number theory and combinatorics, and Python is
great for that. Haskell may have more attraction if you like abstract
algebra or mathematical logic. Here is a really nice article that
explains Haskell's type system in terms of categories:

http://en.wikibooks.org/wiki/Haskell/Category_theory

 

[Paul Rubin]

def gen_s():
s = [1]
m = skipdups(heapq.merge(*[(lambda j: (k*j for k in s))(n) for n in [2,3,5]]))
yield s[0]
while True:
k = m.next()
s.append(k)
yield k

Nice. I wouldn't have been sure that "for k in s" worked properly when
s was changing like that.

There is a space complexity problem compared to the Scheme or Haskell
version: all the s's are saved in the s array, instead of being
discarded once they are yielded. That means generating n elements needs
O(n) space instead of O(n**0.7) or something like that. I guess you can
get around it with collections.deque instead of a list.

 

[Alexander Blinne]

def gen_s():
s = [1]
m = skipdups(heapq.merge(*[(lambda j: (k*j for k in s))(n) for n in [2,3,5]]))
yield s[0]
while True:
k = m.next()
s.append(k)
yield k

Nice. I wouldn't have been sure that "for k in s" worked properly when
s was changing like that.

I just tried it and it worked. Not sure if it is guaranteed.

There is a space complexity problem compared to the Scheme or Haskell
version: all the s's are saved in the s array, instead of being
discarded once they are yielded. That means generating n elements needs
O(n) space instead of O(n**0.7) or something like that. I guess you can
get around it with collections.deque instead of a list.

An Element of s could be discarded, after every one of the three (k*j
for k in s)-generators went over it. I don't think that this is possible
with one deque (at least with the built-in merger of heapq, a
self-written one could be adapted). Storing everything three times (one
deque for every generator) would be a mess as well.

"Manual" garbage collection could be done by discarding all elements
smaller one fifth of the current element of s, because the three
generators already went by them. This could be done with a deque.

How do Haskell or Scheme determine when elements are not longer needed?

Greetings

 

[Tomasz Rola]

How do Haskell or Scheme determine when elements are not longer needed?

Just like Python, they use garbage collection - in one sentence, if it can
be proved the object (not a OO-object, just a piece of data) will no
longer be needed, it can be safely deleted - and the code will work as if
nothing happened, because the proof said it won't need this data in the
future (so you need a right proving technique).

Now, the difference is, Scheme (and Lisps AFAIK) and Haskell (and those
functional langs I heard of) posess one neat data type, linked list. They
also allow for tail-call recursion, which - if one organises one's code
properly - means infinite recursion, if one needs it. Some problems are
expressed in an elegant and natural manner as linked lists (head to be
processed now and rest/tail to be processed later). Such linked lists are
ideal fit for tail-call recursion - you process a head and recurse with
results and tail in place of original list (thus becoming a next level
head+tail list). If no other piece of code stores your current head in a
variable (simply speaking), it can be proven that head is no longer
needed. Once you call your function recursively, head is waiting to be
GC-ed. Your code does not need to worry about this.

Last time I checked, Python didn't have linked lists - arrayed lists are
nice, but their elements can't be automatically GC-ed (or, this requires
very nontrivial GC algorithm), the easiest way I can think would be
replacing them with None manually. I'm not sure if del is
performance-nice.

Also, around the same time, Python couldn't do tail-call, so the whole
point of having linked lists was kind of theoretical.

Even more cool, with lazy evaluation (like in Haskell) one can generate
lists on a fly and process them like they were statically allocated. Say,
you only have a 2GB of ram but would like to process 128GB of list,
generated ad hoc as your program runs? Like, counting all even numbers
less than 2**39 - this is trivial, I know (2**38), but you could run such
code with 2GB of ram. Your code processes head and when it recurses with
tail, the new head (next number) is generated, so it can be processed. And
so on. And thanks to lazy evaluation, you don't need to think about it,
this is the job of compiler to organize your program in such way.

Yes, you could also run it in a loop or simulate lazy-eval manually (with
yield) but the point here is you can have more choice for your algorithm
with some languages and in some other languages (Ruby belongs here, too,
AFAIK) you don't use recursion (too much) even if you'd like to.

Myself, I love more choice, but of course everybody can have his own
preferences.

Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:[email protected] **

 

[Paul Rubin]

An Element of s could be discarded, after every one of the three (k*j
for k in s)-generators went over it. I don't think that this is possible
with one deque (at least with the built-in merger of heapq, a
self-written one could be adapted). Storing everything three times (one
deque for every generator) would be a mess as well.

I think for 3 lists I'd have just merged manually instead of figuring
out the heapq merge. The deque approach sounds straightforward but
often there is subtlety, so I'll have to try it.

How do Haskell or Scheme determine when elements are not longer needed?

Normal gc, once there is no reference to an elemeent it is released.
Actually again there may be a subtlety, if there is a symbol pointing
to the stream. I'll check into this but I think when I tested it in
Haskell, it did the right thing.

 

[Terry Reedy]

Last time I checked, Python didn't have linked lists - arrayed lists are
nice, but their elements can't be automatically GC-ed (or, this requires
very nontrivial GC algorithm), the easiest way I can think would be
replacing them with None manually. I'm not sure if del is
performance-nice.

Python does not come with a linked-list class, but one can easily use
tuples or lists with two items as linked-list cells. One can optionally
wrap such cell in a linked-list class. However, if array lists do the
job, which they usually do, using linked-lists will take more time and
space. The problem being discussed may be a case where they are useful
and make it easier to save space.

Also, around the same time, Python couldn't do tail-call,

Nonsense. A tail call is a call temporally followed by a return. In
CPython bytecode, it would be a call followed by return. In Python code,
it is a call spatially preceded by 'return'. Any "return f(whatever)", a
common operation is a tail call.

I presume you actually mean that CPython does not automatically convert
tail calls into local assignments and a jump to reuse the existing
execution frame instead of a new one. True. A Python interpreter could
easily detect all tail calls at either compilation or execution, but
such conversions would erase call history, leaving gaps in exception
tracebacks and make debugging harder. Depending on your viewpoint, such
conversion might be considered a semantic change.

Selectively converting recursive tail calls has specific problems that
have been discussed on other threads, and it would *still* erase the
call history that one might need to debug. If you do branching
recursion, as with a tree, and there is an unexpected exception, you
most likely really do want to see the complete call path leading up to
the exception. In addition, it is a feature that non-terminating
recursions such as "def forever(): return forever()" get stopped.

In any case, a properly written linear tail-recursive function is,
usually, easily converted to an explicit while loop. So if you want
within-frame looping, write it explicitly. To illustrate one general
pattern:

def tail_rec(a, b=start): # use default arg to avoid nesting
if should_loop(a, b):
return tail_rec(A(a,b), B(a,b))
else:
return term(a, b)

def while_equiv(a, b=start):
while should_loop(a, b):
a, b = A(a,b), B(a,b)
else:
return term(a, b)

In practice, should_loop, A, and B will usually be in-line expressions
rather than calls. There may be additional statements after if, else,
and while headers. In while_equiv, move b=start into the body. Else is
typically omitted from the while version, but I prefer it in the
recursive version.

One downside of the space saving is that the history of a,b values is
invisible unless one add a debug print statement. Another is that the
forever function becomes

def forever():
while True: pass

and Python will never stop it without intervention.

Even more cool, with lazy evaluation (like in Haskell) one can generate
lists on a fly and process them like they were statically allocated.

Python iterators can do lazy evaluation. All the builtin classes come
with a corresponding iterator.

Yes, you could also run it in a loop or simulate lazy-eval manually (with
yield)

There is nothing simulated about yield. Python mostly does what you tell
it to do. You just have to learn how to tell it to do what you want.

 

[Paul Rubin]

Python iterators can do lazy evaluation. All the builtin classes come
with a corresponding iterator. ...

I wouldn't say iterators do lazy evaluation in the Scheme or Haskell
sense. Lazy evaluation imho means evaluation is deferred until you
actually try to use the value, and when you use it, it is computed and
kept around for later re-use (until it becomes gc-able). Python
iterators simply generate one value at a time and leave retention of old
values to be managed by the programmer.

There is nothing simulated about yield. Python mostly does what you
tell it to do. You just have to learn how to tell it to do what you
want.

I'd be interested in seeing a clean implementation of that algorithm
using python iterators.

 

[Terry Reedy]

I wouldn't say iterators do lazy evaluation in the Scheme or Haskell
sense. Lazy evaluation imho means evaluation is deferred until you
actually try to use the value, and when you use it, it is computed and
kept around for later re-use (until it becomes gc-able). Python
iterators simply generate one value at a time and leave retention of old
values to be managed by the programmer.

Ok, I see the difference. You are talking about something like a
memoized __getitem__ that computes and store values as needed.

I'd be interested in seeing a clean implementation of that algorithm
using python iterators.

I already wrote "The problem being discussed may be a case where [linked
lists] are useful and make it easier to save space" -- because, from
what I understood, a moving buffer of temporarily saved buffers is needed.

 

[Tomasz Rola]

Python does not come with a linked-list class, but one can easily use tuples
or lists with two items as linked-list cells. One can optionally wrap such
cell in a linked-list class. However, if array lists do the job, which they
usually do, using linked-lists will take more time and space. The problem
being discussed may be a case where they are useful and make it easier to save
space.

Yes. I made linked lists in Python few years ago, just to test something.
At the time Python was my main algorithmic toy, so I couldn't resist.

However, handling the list felt half Pascal-y and half unnatural. Later
on, I felt I didn't like cramming everything into arrays and switched to
something else.

Nonsense. A tail call is a call temporally followed by a return. In CPython
bytecode, it would be a call followed by return. In Python code, it is a call
spatially preceded by 'return'. Any "return f(whatever)", a common operation
is a tail call.

Actually I was wrong.

http://code.activestate.com/recipes/474088-tail-call-optimization-decorator/

Now I am intrigued because this code just worked a minute ago, on 2.6.

Given this was written for 2.4, I was wrong.

Definitely something I would like to experiment with a bit. The need for
adding decorator takes some joy away but it is interesting.

In practice, should_loop, A, and B will usually be in-line expressions rather
than calls. There may be additional statements after if, else, and while
headers. In while_equiv, move b=start into the body. Else is typically omitted
from the while version, but I prefer it in the recursive version.

You see, I spend quite a lot of time playing with concepts etc. Code
performance is nice to have, but I prefer to maximize my performance as I
write something and move on. If I feel (from my own point of view)
something would be nicer to write with recursion, so be it - even though
some Common Lisp manual advises to use loops because they are faster.
Actually, from what I have tested, this not always is true - both
recursion and loops were comparable speed wise in some simple cases I
checked. This manual is a bit old, and new compiler had its own say about
optimisation, maybe that's the truth behind it.

For cases where I really want speed, proper algorithm (if only I can think
it) and compilation rule. If algorithm codes better with loops, this is
ok. But if it codes better with recursion, this should be ok too, because
if I feel better while coding it, I make less errors.

Python iterators can do lazy evaluation. All the builtin classes come with a
corresponding iterator.

This is fine, but I don't mind having more, like the whole language
supporting the idea of being lazy.

http://stackoverflow.com/questions/265392/why-is-lazy-evaluation-useful

There is nothing simulated about yield.

Yes, yield is real and not simulated. And one can use it to do tricks with
how/when Python evaluates/generates/performs. It is nicer than if I had to
write lazy code in, say, C or Pascal, but it doesn't mean one should only
use one language rather than choose language according to the task,

Python mostly does what you tell it to do. You just have to learn how to
tell it to do what you want.

Well I believe I have already learnt some of it. I am not using Python on
a daily basis nowadays, and I am stuck somewhere in 2.x land. To stay in
this semicurrent state I read this group and, from time to time, some
shorter PEPs. So I think I can tell Python a thing or two, but at the same
time I don't want to tell it everything, everytime. I like telling
things in a language that sounds better, which depends on what I tell,
actually.

Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:[email protected] **

 

[Alec Taylor]

I'm planning to learn one more language with my python.
Someone recommended to do Lisp or Clojure, but I don't think it's a
good idea(do you?)
So, I consider C# with ironpython or Java with Jython.
It's a hard choice...I like Visual studio(because my first lang is VB6
so I'm familiar with that)
but maybe java would be more useful out of windows.

what do you think?

Learn C and Python.

They work well together... you can write Python modules in C (using
Cython or CTypes), and the most popular implementation is written in C
(CPython).

Alternatively learn C++ and Python.

You can can generate C++ from Python using ShedSkin
(http://shed-skin.blogspot.com.au/), and you can write extension to
Python in C++ (http://docs.python.org/extending/extending.html#writing-extensions-in-c).