A Java/Python hybrid?

Like a lot of recent graduates I'm trained in Java and have had it drummed into my head why the software industry likes a rigid, procedural, statically typed, OO language. (I know not everyone agrees so please don't argue this). I myself like Python which is not statically typed or rigid but is small, elegant and readable. I have been wondering for a while whether a OO, procedural language exists with the rigidness of Java but a more Python like syntax. Something like:

class Stack:
  public procedure add(item: T):

  private array : Array(T)

  # etc....

Can anybody suggest something?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Python like syntax?

GvR has been considering adding type ascription to the language. Not sure what particular aspect of Python you like? I dislike whitespace and special names given to functions. I do like the slicing syntax for string and collection handling. Lots of languages do FP better (lambdas are broke and no proper closures). In terms of the OOP aspect, Python rates an ok. Lot's of dynamic languages, though, have better OOP support (Smalltalk, Ruby, Oz, to name just a few) - since you want a static OO language, that wouldn't answer the question.

Anyhow, if you can a little more precise exactly what it is that you like about Python, perhaps a match could be found. The code fragment you give doesn't give much of a clue, but OO classes pretty well look the same to me no matter the language.

Python has closures now.

Python claimed to have the lambda calculus as part of the language for years, even though it didn't really.

Lambdas got a lot less broke around version 2.2 or so. You can now form a closure using a lambda but not using a def. Python's scoping rules are *weird*.

Maybe Dylan is what Dan is looking for.

Dylan did come to mind

As it has dynamic behavior with static typing. But on the surface, the syntax is quite different than Python.

Maybe when Needle is ready, that'll be even closer.

WRT, Python. Guess I need to go relearn the language. :-)

Needle won't ever by ready, b

Needle won't ever by ready, because I've changed my mind about what sort of language I want to program in. :) If you like that style, though, please take a look at Nice instead.

Speaking of Nice

Started to look at it a couple of times, but never got far (being absorbed in Alice for the last 6 months hasn't helped matters). Isaac Gouy did send me Nice Shape example sometime back - and I really ought to link that in with the rest of the examples.


Admittedly from only looking, I was preferring Needle to Nice and similar languages, and was sad to hear it "die".


You can now form a closure using a lambda but not using a def.

You can form a closure with either. You don't get to mutate closed-over bindings, though.

Python's scoping rules are *weird*.

Yep. Pretty much all of it stems from not distinguishing between binding and assignment in the syntax.

python FP to be scrapped?

The following two links seem to suggest that most general-purpose functional programming constructs are going to disappear from Python:



The surviving FP-ness in Python will be list comprehensions.


The 'lambda' keyword is getting removed but closures remain as they have always been. Traditionally 'lambda' was almost always used in Python programs in conjunction with 'map' and 'filter'. So, given that list comprehensions provide a much more readable alternative to those higher-order functions for the vast majority of use cases, Guido decided to remove them. Now, I would have liked to have kept them but in all honesty I almost never find myself wanting to use either 'lambda', 'map' or 'filter' despite that my coding style features higher-order functions and such heavily. I know that Ehud has mentioned that he programs in Python, so maybe he and other LtUers can provide their perspective on this?

Anyway, all in all, I'm not sure it's fair to say that the only surviving "FP-ness" is list comprehensions. In fact, more "FP-ness" is being introduced with the appearance of the 'partial' higher-order function (which performs currying) in the Python 2.5 standard library. (It can be accessed in Python 2.4 by importing it from __future__.)

__future__ of Python

I know that Ehud has mentioned that he programs in Python, so maybe he and other LtUers can provide their perspective on this?

lambda is not easily replaceable by a library function but removing filter, reduce etc. from the builtins into some custom FP module is just usual refactoring and more severe refactorings are expected to happen on Py3K. The status of lambda remains unclear. Some say that the feature should be removed from the language altogether with the "lambda" keyword others just want another syntax. Ironically I like 'lambda' and I wish it had some companions namely 'phi' and 'xi' ;) But this is a different topic and I might come back to this later here on LtU.

For FPL programmers it weights much more that recursion in Python is rather slow and will not be optimized by means of tail call elimination. Guidos prevalence on the OO paradigm may shine through but I don't want to criticise this here simply because his insight is somehow correct that FP is not just a bunch of features but a complete methodology and Python won't ever fit into this. Functions like map, and reduce have clearly not the same significance in Python than map and fold have e.g. in Haskell. Since they are not used recursively but as iterators they are redundant and can be replaced by list/generator comprehensions.

For __future__ I'm not sure that Python will not be superseded by itself? The PyPy runtime[1] is not just a very actively maintained project but the group around Holger Krekel and Armin Rigo where that clever that they get funded by the EU with a budget of 2Mio €. Since PyPy enables extension of the runtime in Python the language becomes finally a programming programming language. Which forces will drive the development of Python if PyPy succeeds in approaching CPython speed no one can tell.


[1] http://codespeak.net/pypy/dist/pypy/doc/news.html

FP features in OO languages

Who said:

"Object-Oriented Programming
in languages that don’t require
tail-call optimizations makes
no sense."


In the presentation "Functional Objects, Functional Classes" Felleisen tries to find common ground between object oriented programming and functional programming.

It contains some very sharp observations.

In terms of the syntax: Th

In terms of the syntax:
  • The whitespace
  • The way the ASCII character set is used sparingly.
I liker the simplicity of the syntax. There are not too many obscure features like condition?true:false in C. Python has a sensible syntax thoughout that hasn't just been copied from C++ without any thought. For example:
  • Java usually requires break keywords in switch and in the rare instances when they genuinely shouldn't be there they look like bugs.
  • var : type is in my view better than type var since the first draws attention to the variable name and makes it easier to 'decode'. Compare apples : int Array of 0..9 to int apples[10].

I'm sure not everybody aggrees with me on everything I said but I hope this clarifies what I mean a bit better. I'll take a look at GvR. BTW I like the slicing syntax too.

Afraid none of that excites me much

Note: You need to close the italics </i>

The whitespace

I'm fairly religious about indentation and structure, but I dislike assigning semantic meaning to whitespace. Indentation is a job for a pretty printer, not a compiler.
The way the ASCII character set is used sparingly
Other languages are even more sparing. I dislike the def keyword for functions, etc...
Java usually requires break keywords in switch and in the rare instances when they genuinely shouldn't be there they look like bugs.
An OO purist would tell you that a Switch statement is a polymorphic dispatch waiting to be refactored.
var : type is in my view better than type var since the first draws attention to the variable name and makes it easier to 'decode'. Compare apples : int Array of 0..9 to int apples[10].
And I would prefer to use languages where type ascription is kept to the bare minimum. That is, if the compiler can determine the type, I shouldn't be required to put it either before or after. But since Pascal was my first love, I'd have to agree that the C declarations are unnatural. :-)

Why does this remind more of the Hitch Hikers Guide to Galaxy?
none of them was entirely satisfactory: either the climate wasn't quite right in the later part of the afternoon, or the day was half an hour too long, or the sea was exactly the wrong shade of pink.
The reasons why I think Python is more readable than Java go much deeper than these items. For sure, they are indicative of the kinds of things that leads to that conclusion. But each of these things could be added to Java without too much contortions (a preprocessor could turn the trick). But it'd still be easy to tell it was Java code - and probably just as hard to decipher.

Edit Note: GvR is Python head of state Guido van Rossum. The addition of type information was discussed previously on LtU.

What's wrong with whitespace?

I'm fairly religious about indentation and structure, but I dislike assigning semantic meaning to whitespace. Indentation is a job for a pretty printer, not a compiler.

Could you explain your reasoning here? I used to think that too but then I realised that whilst working as a C++ developer the only places where code was not ever indented correctly (so that a Python interpreter could read it if it was Python) was where somebody had used tabs. As a student I found it frustrating trying to read other students bad code but whilst I somehow coped with students naming classes after themselves it was the bad indenting that made code impossible to read.

Can you suggest procedural code that breaks the Python whitespace semantics but is more readable than if Python's whitespace semantics had been used?

Just a personal preference

Whitespace semantics "works" fine given the syntax of Python. But I still prefer not to have whitespace have semantic meaning. Styles and idioms are nice things to have, in terms of readibility. But they are a craft that's best left to the programmers. If the programmers fail, then a pretty printer can fix the problem in fairly short order.

The fact that you have C code that's unreadable, owing to layout, is the fault of your code editor. I have my own view preferences when it comes to code - preferences that come about having used a bunch of different languages. Reading code should be as much a matter as conforming the layout style to the reader, as opposed to a universal set of guidelines that match all needs.

Like I said, I was weened on Pascal. As such, I prefer code that is blocked with keywords when necessary that indicates a block or structure is being entered into. It's all a matter of personal preference. What we need is to have the code editors cater to our personal preferences, rather than relying on the vagaries of individual programmers, or the arbitrary decision of the compiler to decide which particular styles and idioms have to be enforced at all costs.

In the end, I don't buy the Pythonista's argument that code readibility hinges strictly on nice neat columnar layout of the code. Probably helps for the degenerate case of programmers that don't have enuf sense to properly lay out things. But generally this same population can screw up readibility in more than one way (each attempt to make things idiot proof, is doomed to creating ever expanding types of idiots).

That said, where assignment of whitespace semantics gets beyond nuisance is in code that is embedded code or code that is saved off in a format other than a text file.

What about Haskell's approach?

What about the approach taken by Haskell, where use of layout-sensitive syntax is optional (that is, layout kicks in locally only if you omit braces at certain well-defined and obvious points)? That should address most of your concerns. I always found it the ideal solution - and Haskell code beautiful indeed.

A fair compromise

Suits my tastes better than strict reliance on layout. Mostly being contrarian on the issue, as it really doesn't make a big difference to me either way. Though I can't help that a language's surrounding culture makes more of a difference in terms of writing maintainable code. Haskell code is easier to read because Haskell coders are immersed in a culture that values elegance. Much Smalltalk code is not bad on the eyes, but in that case the lack of a safety net in syntax actually has forced the culture to rally around styles that are enforced by the power of shun. Layout rules are more a way to encourage good coding styles, than they are the ultimate solution to having all code in the language be easily accessible.

Down with whitespace

I've never understood the whitespace thing of Python, Haskell, Merd, yadda. I mean, what if I ever want to copy & paste code? I know, "you shouldn't ever be copying and pasting code!" but that just isn't realistic. For me. Speaking for myself. And just I.


I've done quite a bit of copy-paste in Python (not so much in Haskell). I use emacs, so I paste the block and then indent it using emacs' python mode, which is what I would have done for pasting C++ code as well. Thus, it doesn't matter to me whether or not the code is correct as first pasted since I always want to keep the indentation neat.

In Haskell, it's never been a problem. I just don't find myself pasting code from a different block. Also, Haskell gives you the option to use '{', '}', ';' instead of the offset syntax. However, I've never heard of anybody going back to the curly braces after getting comfortable with the offset syntax.

Syntax is the Vietnam of programming languages.

I agree... I like slicing too. Though I still find list manipulation in Python somewhat cumbersome, even with slices. You might agree, once you've been seduced by a functional programming language and master its art of list processing. (It's even better if you use pattern matching!)

I thought of Dylan because it's sort of a fusion of Java and Python semantically, and I somehow missed you were talking more syntax. Syntactically, Dylan is its own beast, kinda verbose and conventionally makes moderate to heavy use of ascii.

But syntax is just syntax. I'll take terrible syntax with good semantics over great syntax with bad semantics almost any day of the week.

Your programming prowess would really benefit from learning a radically different language than Java and Python. Most LtU'ers have mastered at least one of Haskell, OCAML, or Scheme. Of these options, Haskell has the most "Pythonic" syntax; OCAML and SML have more of an "ALGOL-ish" syntax, and Lisp/Scheme is in it's own category.

If you decide to explore Scheme, there are a large number of implementations to wade through. I highly recommend Dr Scheme because of its user-friendly syntax editor and integrated development environment. The right editor makes pleasant the often painful Lisp syntax experience.


var : type is in my view better than...

Well Zonnon is probably too traditional for you, so try Scala.

class Stack[T] {
  var elems: List[T] = Nil;
  def push(x: T): Unit = elems = x :: elems;
  def top: T = elems.head;
  def pop: Unit = elems = elems.tail;

Python does functional programming just fine.

Albeit with a tremendously crufty syntax.

Try Nice

a OO, procedural language exists with the rigidness of Java but a more Python like syntax


There are plenty of places where you can compare the source to Java and/or Python

see the comments on Generics vs. Dynamic Checking

see the Computer Language Shootout

see the Code examples on the wiki Scissors Paper Rock etc

Python Like (but how?)

What features do you need?

How about

Eiffel? Not Python syntax, but still elegant imho. And very structured (makes java look loose).

Haskell, maybe

Edit: Sorry, it seems I mistakenly bumped an old thread. I'm not quite sure how I ended up in this thread, actually. I thought I got here through the main discussion forum. I can't see a way to delete this post, so I suppose it's stuck here. (end of edit)

Another edit: Further inspection reveals that I wasn't the one to bump this thread, so I guess it must have caught my eye in "Active forum topics". (end of edit)

Others have mentioned Haskell, and I'd like to point it out as well. It's not particularly OO (but see this LtU post) or procedural, but it's more rigid than Java, and I like its syntax nearly as much as I like Python's. Like Python, its syntax is often whitespace-sensitive.

Because someone mentioned slicing, I'll take the opportunity to show how Python-style slicing might be implemented in Haskell by taking advantage of infinite lists (this is not efficient code):

validIndex xs index =

And it could be used like this (at the interactive prompt):

> let xs = [1..10]
> xs
> slice xs [3..]
> slice xs [0,3..]
> slice xs [5,4..]

Overall, I find Haskell neither as usable nor as practical as Python, but it's a beautiful language and a great way to learn functional programming if you haven't yet.


The Boo language is designed to be a statically typed Python.