Prothon - A New Prototype-based Language

Ben Collins writes "Prothon is a new industrial-strength, interpreted, prototype-based, object-oriented language that gets rid of classes altogether in the way that the Self language does. It uses the sensible, practical syntax and add-on C module scheme from Python. This major prototype improvement over Python plus many other general improvements make for a clean new revolutionary breakthrough in language development. Prothon is simple to use and yet offers the combined power of Python and Self. Check out the first public pre-alpha release at prothon.org."

Pre Alpha Release?

A pre alpha release really isn't newsworthy. Is this some one's pet project? I wasn't aware Python was broken.

Re:Pre Alpha Release?

Well, it would be newsworthy if it were a pre-alpha release of Duke Nukem Forever.

Re:Pre Alpha Release?

Well, it would be newsworthy if it were a pre-alpha release of Duke Nukem Forever.

Yes, hell freezing over and the end of all mankind would be newsworthy, wouldn't it?

Re:Pre Alpha Release?

A pre alpha release really isn't newsworthy. Is this some one's pet project?

this language doesn't just use prototypes... it is one.

Why is there only one database access language?

There are sooo many general programming languages but only one database access languages: SQL? SQL is so old, it hurts. It's basically COBOL.

Ok, there is one additional database access language I know of: NewSQL (http://newsql.sf.net).

But it seems nobody is really interested in database access. And everybody is interested in all kinds of general programming language. Why is that?

Re:Why is there only one database access language?

Thats a good question, but I would say that because in general (arguably because SQL is so limited) there has been a seperation of data storage and application logic paradigm. Its similar to why filesystems dont have lots of complex logic constructs built in to them.

You might question the eveolution of how much we push into the platform level though. For instance the hot libraries/tools people are playing with are things like object serialization packages, cheap DB replication, etc. These are places where application space is trying to address lack of evolution in data storage space and might be good candidates for new storage interfaces.

Just a thought..

Re:Because SQL works

You can use regexp's if you use Postgres.

Re:Because SQL works

how is sql in any way inadequate?

Ok, lets say you have an invoice system that maintains "customer"s, "bill"s, and "payment"s in seperate tables. The relationships are as follows: One customer to many bills and many payments. A seperate table "paytobill" (with an amount field) is used to link bills and payments as some customers may make a single payment covering several bills, or several payments to cover a single bill (like a payment plan).

Now, give me a report showing every customer, and the most recent bill that each customer owes money on (if they have any), and how much they owe. Using strictly these tables (ie no fields that are updated by a trigger) it is incredibly hairy. Your choices are pretty much to execute a query on "paytobill" inside a loop from "customer left outer join bill", or to do something really hairy like this (postgres syntax) (we'll assume that bill.id is ascending:

select c.name, bq.billdate, bq.cost-coalesce(pq.amount,0) as unpaid from customer c left outer join (select b.customerid, b.billdate, b.cost from bill b where b.id=(select max(bm.id) from bill bm where bm.customerid=b.customerid and b.paid='f') ) bq on bq.customerid=c.id left outer join (select b.customerid,SUM(pb.amount) as amount from paytobill pb join bill b on pb.billid=b.id where b.id=(select max(bm.id) from bill bm where bm.customerid=b.customerid and b.paid='f') group by b.customerid) pq on pq.customerid=c.id

Not pretty, is it? Now, look at how that could be done with less language and more readability by adding a single keyword and slightly redefining the syntax:

select c.name, b.billdate, b.owes-coalesce(sum(p.amount),0) as unpaid from (customer c LIMITED left outer join (bill b LIMITED left outer join paytobill p on p.billid=b.id GROUP BY b.id, b.billdate, b.owes) on c.id=b.customerid ORDER BY b.billdate DESC LIMIT 1)

Here, its clear that we're joining "bill" and "paytobill" and collapsing that table immediately to generate sum(p.amount). Then, we order this collapsed table on date, and left outer join against "customer", BUT we only take one row from the collapsed table for each customer (if it speeds the join, we could even ditch those unused rows now to further shrink the table). Drawbacks include the use of () to clarify what grouping and limit we mean. Even though the LIMITED keyword could mean that the next GROUP BY/LIMIT keyword belongs to the join, what if both were used, without a WHERE clause to indicate where the joins ended and the main query began?

The query planner would have to be able to identify the request for SUM(p.amount) as being related to the GROUPed limited join. The planner would then create the intermediary table and calculate the aggregate values on that table using the given group by. Then the query planner would order the intermediary table and join it with the customer table, selecting from zero to the limit number of right-hand rows for each left-hand-row The syntax above makes it fairly clear what the query planner should be doing.

The command in SQL would involve a nested loop [select max(...)...] (two, if the planner wasn't smart enough to recognize that the two copies of it are identical, which most won't be since they are in seperate branches of a left outer join) (it's possible that a brilliant query planner might be able to make the jump and create an intermediary table of <bill.customerid,MAX(bill.id)> for reference in both branches of the query). In addition, unless you have a brilliant query planner, you'll end up working with potentially very large intermediate tables.

Re:Because SQL works

Well, for one thing your indenting sucks which makes any piece of software hard to read.

For another thing, your design is unsound from an accounting standpoint. A sound design requires that payments are explicitly applied to bills in our record keeping system whether it is electronic or paper. It's the old debits and credits thing. Your accounting records should not use some kind of magical algorithm to figure out which payment record goes which which bill and then use a separate maguic table to override that logic. Every change in an acount/bill/payment status should be explicitly spelled out in records in a transaction table. These records are either filled out at the explicit directions of a human or by created by an algorithm -- it doesn't matter. The change in the bill's balance needs to be be explicitly recorded.

Given this design, the payment table in your query is totally superfluous. Everything we need to know is in the paytobill table. What you are asking for is not that hard (for an expert):

select customer.custId,
bill.billId,
billAmt - coalesce(sum(payToBill.applyAmt),0)
from customer left outer join
bill on bill.custId = customer.custid left outer join
paytobill on paytobill.billId = bill.billId
where
bill.billdate =
(select max billdate from bill
where bill.custId = customer.custId)
group by customer.custId, bill.billId

Which is much less nasty than your SQL. Granted, SQL programmers don't always have the ability to work with sound schema designs; on the other hand, it's always possible to create designs that are hard to use.

I'm not saying SQL couldn't be improved. It also needs the ability to compare anonymous tuples with tuples returned by a subquery -- only allowing scalars with the "=" operator is a huge limitation to the working SQL programmer.

Also, the standard needs to be a lot more stringent, and there should be tough conformance tests. The Microsoft SQL Server, for example is a disgrace -- it doesn't allow alias references in expressions for one thing, and has truly horrible bugs in prepared query variable binding.

Re:Why is there only one database access language?

There are sooo many general programming languages but only one database access languages: SQL? SQL is so old, it hurts

Arabic numbers are old too, but I don't see anyone proposing to change them.

SQL is an English-like representation of relational calculus. Relational calculus has not, and is not going to, change significantly. When the problem is solved well, there's no need to change the solution.

SQL is like COBOL????! WTF??

Errr , have you ever use EITHER language?? SQL is a declarative set driven language and works in a COMPLETELY
different way to COBOL which is procedural. I think you need to go back and re-take compsci 101!

Re:Why is there only one database access language?

There are sooo many general programming languages but only one database access languages: SQL?

There are more than that. Here's one: Xplain [berenddeboer.net]. That page describes a converter to SQL, so you can write Xplain queries and make them against a standard DBMS. I don't know much about this language, as I just learned of it recently.

There are many others which are not based on the relational model. It's difficult for me to take them seriously, as the relational model is so powerful.

SQL is so old, it hurts. It's basically COBOL.

I don't care how old it is. What's wrong with it?

By "is basically COBOL", are you complaining that it favors words over symbols? I do not find this to be a problem. My SQL queries are short enough and a small enough part of the whole program that I prefer the clarity over any additional possible terseness. COBOL is different in that whole programs are written in it.

If I were to make any complaints about SQL, they would be:

• null lumps together "unknown" and "inapplicable". For this reason, a lot of people find the comparison rules for "x == null" and "x null" confusing. If these were separated, I think more logical behavior would be possible. (Dr. Codd, the relation algebra guy, proposed having multiple types of null at one point.)
• it requires you to match up pairs of lists in several situations:
  • insert into table (column_a, column_b, column_c)
    values (value_a, value_b, value_c) ...which looks okay there, but gets hard when you have too many columns to fit on one line. Versus insert into table (column_a => value_a,
    column_b => value_b,
    column_c => value_c which is always clear.
  • insert into table (column_a, column_b, column_c)
    select 'foo',
    'bar',
    column_c
    ... versus insert into table
    select 'foo' as column_a,
    'bar' as column_b,
    column_c
    ...
  • $sth = $dbh->prepare('insert into mytable values (?, ?, ?)');
    $sth->execute($foo, $bar, $baz); versus $sth = $dbh->prepare('insert into mytable values (:foo, :bar, :baz)');
    $sth->execute(foo => $foo,
    bar => $bar,
    baz => $baz); I think the placeholder syntax is not actually specified by the SQL standard, but it should be. The '?' syntax is dumb. The named syntax should be mandatory. In most DBMS/API combinations, only the '?' syntax is available.
• there are no parameterized views. I'd like to be able to do something like

  select *
  from latest_chronological_v(some_date)
  where ...

  instead of the

  select *
  from chronological_table
  where date <= some_date
  and not exists (
  select 'x'
  from chronological_table later_entry
  where later_entry.group = chronological_table.group
  and later_entry.date > chronological_table.date)

  that I need now to do whenever date is not sysdate. (I believe SQL-99 has something like this, but it's not implemented in PostgreSQL or Oracle.)

Re:Pre Alpha Release?

A pre alpha release really isn't newsworthy. Is this some one's pet project?

That's what it sounds like to me.
Someone has an idea, makes a sourceforge page for it, gets some developers, writes up his ideas full of marketspeak. What happens to it? About 95% of the time, it dies a long, slow death.
That's pre-alpha, folks! I'll be happy to look at it when it reaches 1.0, but until then, I'm playing the odds.

I wasn't aware Python was broken.

Perl wasn't broken when Python was made, right? Adding another language never harms anyone, really. If it proves to be powerful, people will use it. If it proves to be clean and easy to understand, people will use it as a learning tool. If it doesn't offer anything better than any other language, it will die. Its just the evolution of coding languages.

Hell, if everyone followed the philosophy of "well, [programing language] isn't broken, why make another." We'd all be programming in assembly... or worse, bytecode.

Pity about the name

Sounds like a korean car.

Re:Pity about the name

Maybe it's a cunning anagram of "hot porn".

Re:Pity about the name

Maybe it's a cunning anagram of "hot porn"

Thanks a lot dude. I'll never be able to use "prothon" without thinking of "hot porn" now.

You pretty much have managed to kill it right out of the box.

Re:Pity about the name

Thanks a lot dude. I'll never be able to use "prothon" without thinking of "hot porn" now.

{puzzled} You say that as if it were a bad thing.

Re:Pity about the name

Well, let me kill some other languages for you -

Python - Hot Nyp(ple), Not Hyp
COBOL - B Cool
FORTRAN - Rant Fro, Nor Fart
Lisp - Slip, Lips
Objective-C - Object Vice
BASIC - I Scab

And the most horrific of all....

C - C !!!!

How can they...

call it "Industrial-Strength" if it's "pre-alpha?"

Re:How can they...

call it "Industrial-Strength" if it's "pre-alpha?"
Microsoft gets away with this every time....

YANISL: Just What We Needed

Yet Another New and Improved Scripting Language! Just what we needed!

Oops, did I say that out loud?

Re:YANISL: Just What We Needed

A new language is here! A new language is here! I needed something to go between "Perl" and "Python" in my alphabetical index of languages.

Re:YANISL: Just What We Needed

Not improved - just as bad:

"Like Python, Prothon uses indentation ..."

Oh joy.

THL.

Re:YAL (INTL)...

I've been paid (as in, it was part of my job at the time) to write code in: APL, Assembler, Basic, C, C++, Cobol, Fortran, Java, JavaScript, Pascal, Perl, PHP, PL/I, PostScript and SQL (plus variants of some of those), as well as job control languages like JCL and WFL, simple scripting in sh and csh, several proprietary application-specific scripting languages like MITS, SPSS, GML and GSL, and miscellanous markup languages (troff, formal, HTML, XML, rtf, etc). And a half-dozen different text editors (CANDE, Teco, FIX, vi, emacs...)

I've probably left a few out, and that's not even mentioning languages I learned incidental to a class assignment (GPSS, Simscript II and Simula for a course on discrete event digital simulation, SNOBOL for something on text processing, Lisp).

The point is not to brag, but to point out that any professional software developer should be both expected to know several languages and should expect to learn and use several more over the course of his career. (But if you're going to mention it on a resume, give some indication of skill level -- expert, experienced or just "I wrote a 'hello world' in it once"?)

A mechanic is expected to have a pretty complete toolkit, with both metric and imperial wrenches, slot and Phillips and Torx screwdrivers, etc. -- and in Canada, Robertson screwdrivers too. (OTOH, he probably doesn't need a left-handed blivet impeller unless he's just into collecting tools for their own sake.) Somebody designing a product to be built -- whether a machine or a software system -- needs to be aware of what tools and materials are available to build the product with, and to maintain it. (In this regard progamming languages are more like materials than tools, either way they should be chosen for their properties.)

Maybe they should write a new webserver

Maybe they should write a new webserver in Prothon... to survive the slashdotting...

Re:Maybe they should write a new webserver

They would if it wasn't easier to do in python.

Here we go....

with the "witty" names again. Anyway, can someone explain to me how eliminating classes is better? I thought that implementing classes, the OOP approach, was the better way to go.

They don't really explain why their way is better. They just state it as though it was a matter of fact.

Make your vote count [linuxsurveys.com]

Re:Here we go....

Prototype languages still hold many of the OO concepts, but objects are created directly. That is, a "blueprint" approach (i.e., the class) is not used in the creation of objects. Inheritance still works by cloning and modifying existing objects. Although this makes sense in some ways (ideas like the Singleton pattern fit more nicely in this paradigm), in reality prototype languages gain features that make them more and more class-like. I'm not a big fan, personally.

Re:Here we go....

So why do you assume OOP is the better way to go? I don't assume that OOP is the better way to go. I know it is from experience. I work with a lot of OPC (other people's code for those who don't know the term), and let me tell you, working with objects is about 10x easier for maintence, and for adding functionality. OOP isn't an excuse to code poorly though, I will take non-OOP that is well written over OOP that is poorly written, however as most of the code I deal with is poorly written, the OOP does make it easier.

OOP enables you to easily swap out modules, or replace existing code. As long as you know the inputs and outputs of an object, it can be seemlessly removed for a newer version. This makes maintence much easier, and so long as public/private/protected conventions are followed, it can allow for some really smooth upgrades.

IMHO inheritance is an overrated feature of OOP, I primarily like it because it forces people to work in a black box model, which makes the whole problem of updates and bug fixes 100x easier for the person who has to deal with your otherwise crappy code.

Prototype-based Prothon ehh?

Call me when Producthon is ready.

industrial strenght ???!!!

Obviously, the web server is not industrial strength, at least not /.proof.

As for industrial strength of the langage, knowing some industry guys, some pre alpha system is certaintly not ready.

Tabs, no classes

At firest reading about the tab thing, the bile swelled up. (Heck, my vim config won't even let me type a tab anymore.) But it's not really a bad idea. I can see how it will incite flames, though.

I didn't see much in the way of code examples on the site. The "no classes" thing confused me and I would have loved to see some example Prothon code that accomplishes the kinds of things that I would have used a class for, in Python.

Re:Tabs, no classes

In no natural language does the case of a character convey information that cannot be gained from context.

German:
"Mein Sohn soll Forscher werden." = "My son shall become a researcher."
"Mein Sohn soll forscher werden." = "My son shall become more snappy."

Re:Tabs, no classes

Not to mention Danish and danish ... one is a language and a nationality, the other is a pastry.

p fixation?

What's with all these languages that start with 'p'? perl, python, php, not to mention good old pascal, and now prothon. Is there a joke here that I'm missing?

Re:p fixation?

The truth is that the vast majority of programmers need to use the bathroom *really* badly. Hence the p fixation.

Shhhh...

Prothon is a new industrial-strength, interpreted, prototype-based, object-oriented language

Haven't seen so many buzzwords in one sentence for a long long time...

Re:Shhhh...

An even better piece of buzzwords, though fabricated, from the TUNES FAQ [tunes.org]:

A proven 32-bit cutting-edge state-of-the-art industrial-strength Y2K-compliant zero-administration plug-and-play industry-standard Java-enabled internet-ready multimedia professional personal-computer Operating System that is even newer and faster yet compatible, with a user-friendly object-oriented 3D graphical user interface, amazing inter-application communication and plug-in capability, an enhanced filesystem, full integration into Enterprise networks, an exclusive way to deploy distributed components, seamless network sharing of printers and files.

A work of art, except that it doesn't have "XML" in it somewhere.

Bondage

This is taken from the Prothon Description [prothon.org]

Like Python, Prothon uses indentation to control the block structure of the program instead of block/end or {}. However, Prothon only allows tabs for indentation. Any space in an indent will cause an error.

Classic bondage-and-discipline. Why oh why is this so ??

Re:Bondage

I can think of two good reasons:

1. If you're using indentation for structure, then it's horribly confusing to allow both tabs and spaces. How many spaces is a tab worth? You could add a "tabsize=" variable to the core language, but you have to be able to parse a file before you can start evaluating it, so that would necessarily have to be an ugly hack.
2. An (old) Python topic-of-heated-discussion was the relative merit of tabs vs. spaces. Setting one as the standard avoids the whole issue and lets everyone get back to work.

My only gripe is that out of the two choices, they picked the wrong one <ducks>.

Re:Bondage

Yeah, that's why indentation as block structure is a ridiculous idea in the first place!

<ducks>

Re:Bondage

And at least I can see a { or } in printed code. Seeing white space is altogether more difficult!

Not completely true. Seeing _whitespace_ is impossible; seeing _indentation_, however, is extremely easy. In fact, it's enormously easier than seeing { and }; consider the fact that many C bugs are of the form

if (something)
do_this();
do_that();

...where "do_that" appears to most people to be conditional, but is actually unconditionally executed.

-Billy

Karma Whoring

Prothon Description:
This document assumes a working knowledge of Python. Many features are described as differences to Python features. If you are new to Python, a good starting point can be found at www.python.org.

Comments

Standard Python comments using the # character work exactly the same in Prothon. Prothon also supports the C comment format of /* and */. This is useful for temporarily blocking out large blocks of code and inserting inline comments.

# this line is a comment
x=5 # this is a trailing comment
if not rlst /*no response*/ or is_too_long:

Indentation is Tab-Only

Like Python, Prothon uses indentation to control the block structure of the program instead of block/end or {}. However, Prothon only allows tabs for indentation. Any space in an indent will cause an error. This allows each programmer to set the editor to show the tab width to whatever he pleases and the Python problems of mixed spaces and tabs cannot happen in Prothon. It also allows for minimum typing.

Line Continuation

A line can be continued by placing a backslash ( \ ) as the last character of a line as in Python. Also, any tab indent of more than one level deeper than the previous indent level will cause the line to be considered a continuation of the previous line, which is a new feature to Prothon. The automatic continuation of lines in comma separated lists found in Python is not allowed in Prothon because of parsing differences, but usually the auto-continuation from indents alleviates the need for this.

Note that you can put spaces after tabs when in an auto-continuation. This allows you to line up the continued line for appearance.

x = 1 + 2 + 3 + 4 + \
5 + 6 + 7 + 8 + 9 # backslash continuation

s = "this is a normal line \
this is a continuation" # backslash works in quotes

y = long_function_name() +
another_function_name() # extra indent continuation

z = function_name(variable_name_1, # this is legal in Prothon because
variable_name_2) # of extra indents, not commas

Variable Names and Scope (No more "self variable")

The syntax for a variable name (label) is the same as Python except that one exclamation mark is allowed at the end and only at the end. This usage should be reserved for functions that modify the object's content in place. This allows a function such as list.sort!() to return the modified list, which was not allowed in Python. One should ALWAYS use this naming convention for in-place modification functions to warn programmers.

Prothon has a very different concept of self than Python. Any and every object can be "self", whether the code is in a function or not. So the Python tradition of using the variable named "self" does not fit in Prothon. The next section shows how an object becomes the "self". For now just imagine that somehow there is always one special "self" object at any one time.

Prothon code needs a way to differentiate between local variables, attributes in the self our code is running on, and global variables (in Prothon, globals are attributes of the module running our code). Prothon is introducing a relatively new concept in order to make it very easy to know which of these three types of variable you are referring to. This is the use of character case. Just as Python pioneered the use of white-space (indentation) to control syntax, Prothon is using case to control syntax.

Local variables always start with a lower-case letter or underbar ( _ ). Global variables always start with an upper-case letter. Attributes in the self object are prefixed by a period ( . ), but the name of the attribute itself can start with any case.

def .get_hdr(text): # define func "get_hdr" as attribute of self .text = text # attribute "text" loaded from local "text" .hdr = Mime

text of website Prothon

Why a new language?

Python is a interpreted language with object-oriented features that is practical, powerful, and fun to program at the same time. Over time capabilities have been added to the core Python language, while compatibility with earlier versions has been maintained, and Python has became loaded with features, some quite complex. The metaclass is an example of a recent feature addition. Even Python experts admit that metaclasses are brain-achingly complex.

Prothon is a fresh new language that gets rid of classes altogether in the same way that Self does and regains the original practical and fun sensibility of Python. This major improvement plus many minor ones make for a clean new revolutionary break in language development. Prothon is quite simple and yet offers the power of Python and Self.

Prothon is also an industrial-strength alternative to Python and Self. Prothon uses native threads and a 64-bit architecture to maximize performance in applications such as multiple-cpu hosting.
What is Prothon like?

See a quick description of the Prothon language.

Take a look under the hood at how Prothon is implemented.

Summary of differences from Python.
Development status?

As of 3/04 Prothon exists as a pre-alpha interpreter with minimum capabilites, just enough to try out the language.

Summary of currently implemented functions. Known problems.

Tested platforms: i386-linux, , sparc-linux, sparc64-linux, i386-Win2K, i386-XP, Dual-Opteron-Win2K

Target Schedule:

7/04: Freeze core language specs (keywords, etc.)

10/04: Release version 0.1
Download

Stable (build 115) Source tarball (175 KB)

Stable (build 115) Windows executable zip file (400 KB)

Latest (probably broken) SVN access: svn://svn.prothon.org/prothon/trunk

Latest source view and tarball: http://www.prothon.org/viewcvs/trunk
How can I contribute?

(Mailing list)

For now, the biggest contribution you can make would be adding to the discussion of 0.1 features. Please join the mailing list. Of course helping with the coding effort is always welcome.
Credits

Language design & win32 coding: Mark Hahn

Linux/Unix coding: Ben Collins

.NET?

So, when can we expect Prothon.NET?

Me, I can't wait for Intercal.NET and Brainfuck.NET

Re:.NET?

Brainfuck.net ... 8 whole instructions...this needs simplification...and bytecode!!!

even better

http://www.iolanguage.com/ [iolanguage.com]

Like school in the summer time

Found a little example code inside the tarball, that shows what they mean by no classes:

Emp_proto = Object()

with Emp_proto: .name = ""

def .__init__(name): .name = name .hello()
return .

def .hello():
print "My name is:", .name

Emp_proto.hello()
emp = Emp_proto("Jim")
emp.hello()

When things come together, they combine ...

Anytime a programming language "combines" the power of X with the simplicity/power/convenience of Y, what it really means is, "Here's a new set of compromises and we're calling it this, but the marketing guys are making us say that it's a new way of slicing bread."

Bottom line, someone wanted Python with prototypes. I'm not sure that prototyping -- creating objects from other existing objects by copying, essentially making inheritance a "first class" consideration -- is an analogy that's going to truly redefine the way I look at programming. Or let me put it this way, I'm not at all sure that the benefits of prototyping are going to make me want to restructure -- yet again -- everything I know about programming so far. I mean, after a certain point, programming is a job and I have to produce, not just theorize all the time about new approaches.

Also, judging from Sun's tutorial [sun.com] on Self, it doesn't seem ready for primetime, so I'd be a little edgy about "Prothon".

Prothon. God.

I dunno. This may seem curmudgeonly, but it is, after all, yet ANOTHER language ... Sigh.

Not 'instrustrial strength'

I'm a bit of a 'language lawyer', so new languages that try to solve problems in interesting ways always interests me. So... I decided to give it a good reading. I got turned off IMMEDIATELY as I saw the following text:

"Unlike python, there is no 'global' keyword. Any variable name starting with a capital letter is global."

(Taken from memory... the prothon site is a bit slow at the moment, for some odd reason ;) )

That is NOT the sign of an 'industrial strength' language.

Re:Not 'instrustrial strength'

I refuse to even consider ANY language that is whitespace sensitive

It's never cool to brag about an unwillingness to learn something new. No matter what other good things you might have heard about Python, you refuse to even try to get past the formatting? That's really sad.

Question to mods: what part of that comment justified "informative"?

Re:Not 'instrustrial strength'

This is something they inherited from Smalltalk.

Honestly, I don't see the problem. Virtually all languages have some sort of global namespace -- the class and package hierarchy in Java, imported functions or global variables in C, etc. Most programmers seem to adopt nomenclature to identify the scope of a variable. I see a lot of _underbar for member variables, ALL_CAPS for constants, UpperCaseNames for classes in Java and C++, etc.

What this does is (1) enforce such a standard, and (2) make it instantly apparent what the scope of an identifier is.

Contrast with Java (which is industrial strength -- I'm currently on break from writing transaction processing systems in it). Class names are global in Java within the scope of your package imports. Sun recommends you CapitalizeYourClasses and doNotCapitalizeLocalsOrMethods. However, that doesn't keep the occasional VB/C# programmer from falling into your lap and doing everything wrong, which can make the code awfully hard to read.

I'm not generally a fan of bondage-domination languages, but this is a case where I make an exception. (I'm also a fan of the scoping characters used in Ruby, for example.)

Self, Python, and Java

Yeah, it's a lot like Self, mixed with Python syntax. Self had a lot of interesting ideas. It never really got out of the starting blocks, but some of its most important ideas in dynamic compilation went on to be included in the Java hotspot compiler.

Personally, I prefer a bit more bondage-and-discipline in my languages. That's because I like having the compiler tell me what I'm doing wrong as much as possible. It's a side effect of the environments in which I tend to work, with multiple people working on the same code. Strong typing is an important contract in such an environment. But it has a lot of downsides, as every perl and python programmer knows.

Oh, and dude, if you're going to submit your own damn web site to Slashdot, try getting a sturdier web server first.

So, then....

What does Prothon do that Lisp doesn't?

Come to think of it, what does *anything* do that Lisp doesn't, except have larger market penetration?

Industrial strength trial size

From the website:

Prothon is also an industrial-strength alternative to Python and Self...

followed by the phrase just four paragraphs later

As of 3/04 Prothon exists as a pre-alpha interpreter with minimum capabilites, just enough to try out the language.

I believe the correct phrase would be Prothon is intended to be an industrial-strength alternative to Python.

(Yes, I know others have said things similar to this, I just think this is more clear; I read all the comments before the site came up and this juxtaposition still struck me.)

If it's nae Lisp, it's Crrrrrrap

Sorry kids, I've had my epiphany.

Is it dynamic (can I define functions at runtime)? Is it compiled? Can I easily write code that manipulates code? Are functions first class objects? Can I extend the language seamlessly?

Some new languages are interesting, but most are built by people who have used and understood far too few of the current ones.

Ahhhh, Lisp -- and its true believers!

Yes, you too can become a fanatical Lisp user! Just trawl for any online discussion of any programming langauge that is not Lisp, then post using the following handy form:

Derogatory or condescending salutation. Quasi-religious statement of love for Lisp.

Laundry list of several nifty Lisp features. (It doesn't really matter which ones.)

Implication or outright statement that every feature in programming language in question has already been implemented in Lisp. Subsequent dismissal of language in question.

Remember, in writing your post, it is essential that you adhere to the following guidelines:

• Never show any respect for a non-Lisp language.
  
• Never admit the usefulness of new experiments, or of personal exploration.
  
• Never contribute concrete, constructive suggestions to the designers or users of any other language.
  
• Never, never think outside the Lisp box.
  

(Disclaimer: I like Lisp. Actually, I love Lisp. It really, truly is incredibly awesome. It's just Lisp users that drive me crazy.)

<ducks REALLY low>

Syntax

Any language that uses whitespace or backslashes for line continuation is madness. This 2004 people. Write a damn compiler that can do the thinking, don't make me screw around with formatting to get my program working. Moronic. Stupid.

Re:Syntax

Any language that uses whitespace or backslashes for line continuation is madness. This 2004 people. Write a damn compiler that can do the thinking, don't make me screw around with formatting to get my program working. Moronic. Stupid.

This is as logical as saying: "Any language that uses curly braces for block delimiters or semicolons for statement delimiters is madness. This is 2004 people. Write a damn compiler that can do the thinking. Don't make me screw around with punctuation to get my program working.

The whitespace and backslashes are not in addition to something else that unambiguously describes the structure. They are instead of the stuff that other languages use (curly braces and semicolons).

There is also Slate.

From Slate [tunes.org] website:
Slate is a prototype-based object-oriented programming language based on Self, CLOS, and Smalltalk. Slate syntax is intended to be as familiar as possible to a Smalltalker...

It also features optional type declaration. The compiler is currently based on Common Lisp.

Here is a tip for the creators of this language.

Prothon Description

This document assumes a working knowledge of Python.

Those of us who are unfamiliar with these {dynamic | scripting | kiddie | hack| toy} languages but curious about the classless way of working are not really helped by this document.

If you go to Suns Java site, they don't say "If you are not familiar with C++/Smalltalk, you might as well fuck off."
Similarly Microsofts site for C# doesn't say "Go learn Java, and then find out about GOTO, and you might have a prayer of understanding this."

A good intro with no dependencies will help build momentum for your project.

The good and the bad

The good parts are the implementation: multiple interpreters (no globals), stackless, gc running in separate thread and generally a clean implementation from scratch.

The bad part is from a language design point of view it's a hodge-podge of small yet significant changes from Python, almost none of them, IMHO, an improvement over Python. Those that may be considered a slight improvement are hardly worth breaking compatibility for.

Significant case? Another type of comment? for i in 7 ? a differnt keyword to define generators? Return self by default? removal of class statements for javascript-like object orientation? WTF?

The Python implementation could definitely use an overhaul. The language itself has a few minor warts but strikes a fantastically well-balanced sweet spot that will be difficult to beat. I just can't see the real justification for these changes other than "because I can".

Tabs

One thing that annoys me about Python-like languages that this new language seems to keep is the reliance on space-count indentation. If you switch editors or share a lot of code, then spaces mixed with tabs can cause a lot of confusion because there is no standard interpretation for how many spaces a tab is.

I agree that it makes the code smaller, but at the risk of code sharing problems.

A plea to all up-and-coming language designers

Before you go off and try to code up the Next Big Thing, please do all of us a favor and learn a little bit about Lisp.

Don't learn about it from your officemate, or your college instructor, especially if they say they haven't used it in over ten years. You wouldn't believe the opinions of someone who learned C from K&R [thefreedictionary.com] without upgrading their knowledge, would you?

Instead, start from places like the ALU web site [lisp.org] or Cliki [cliki.net] or Paul Graham's Lisp FAQ [paulgraham.com].

If you do this right, you will learn that computer languages:

are not inherently fast or slow - implementations are fast or slow, not languages

can be both dynamic and have good performance

can be cross-platform without swallowing POSIX whole

can have multiple inheritance without damaging your brain

can be object-oriented without being object-obsessed

If you like, you can quit as soon as you understand how static scoping and closures work - at least that way you will avoid the primary mistake in pretty much every recent scripting language.

There is a small risk you will become a SmugLispWeenie [c2.com] by doing this, so be forwarned.

need IDE more

I do a lot in VB and that is not because I like the language, but because it has such a good IDE (read intellisense). If I had to program VB in Notepad /Emacs/ whatever, I would slow down by at least 50%, probably 75. You can never convince me that this new language will deliver a better productivity gain then designing a Python IDE which knows all your classes and does auto-complete.

There's another name for Prothon: Python

We already have perfectly good prototype-based programming in Python. Do a search for "metaclass programming in python" for links to my articles on this topic. You can do -everything- with Python metaclasses (which isn't to say you -should-).

But actually, prototype programming is even simpler:

new = old.__class__(init, args, here)

Just what 'old' is is determined at runtime. And if you like, you can poke around at 'obj.__bases__' to futz with inheritence.

Not having read my _Charming Python_ articles isn't really a sufficient reason to create a new programming language.

Nothing to see here....

Having examined this language in some detail, I'm a little disappointed by its design.

1. It makes overly heavy use of punctuation. I'm of the opinion that languages need to be more human-readable, not less. Put another way, the speed and power of coding in any language is not gated by the number of characters it takes to type out a statement; it's gated by the time it takes to find and detect bugs and flaws. Words > punctuation for readability.

2. Many of the design decisions are obviously influenced by one person's peeves with existing languages. The world already has one Larry Wall, and as wonderful as he is, we don't really more Larrys.

3. Elegance is a hard thing to measure, much less quantify. Still, aside from simply being a unique language, it doesn't really offer any new elegance to the concept of what a language should do.

It's an impressive hack, to be sure. I'd be proud to be able to show off a body of code like this, for its demonstration of sheer technical strength. But I find its artistic merits somewhat lacking for my own tastes.

marketing/spin contradiction

Prothon is a new industrial-strength [...] language... Check out the first public pre-alpha release

This might be the first time I've seen a product described simultaneously as "industrial strength" and "pre-alpha".

The 90s Called...

Prothon is a new industrial-strength, interpreted, prototype-based, object-oriented language

They want their new economy bullshit buzzword generator [dack.com] back.

check out Lua: prototype-based, mature, popular

If you want a nice, clean, prototype-based OO scripting language, check out Lua [lua.org]. Its implementation is mature, it is widely used (a favorite among game developers), and it compiles into compact executables. It also has one of the fastest scripting language interpreters around (short of a JIT). And there are excellent tools for binding C and C++ code to it.

Prototype-based programming can be done in Python

It is already possible to do prototype-based programming in Python [canonical.org]. Also in Perl [membled.com]. But the syntax may be a little awkward.

Re:Uh

Of course we need more programming languages. That is how we learn how to make programming languages better.

Sure, only a small number of languages become popular in the end. But that doesn't mean the unpopular ones don't have academic value.

Cheers.

Re:Just what I need:

Until all the development of new programming languages stops, I'm sticking to punch cards.

Re:Who cares?

>The truth is that C/C++/C#/Java/VB/Perl/PHP are the most used.[...]>It has been like this for years.

Is that in itselve a good reason not to care about new stuff at the horizon? 'Guess not, but Without a backing of a huge corporation or a huge number of people, no new language would be used. OK. So which companies initially backed Perl, C++, PHP? None. And there were never a huge number of people waiting to volunteer on building a huge code base for these things (and not for others).

They became popular due to huge numbers of individuals that got over their childish "Who cares?" and judged after taking a good look. You should too. Then tell us about why this thing suck or is just not more of an improvement over existing stuff as is C# over Java.

Then again, better, smaller, faster, is no match for cheaper, more accessible, and well-marketed