Slashdot Mirror
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."
A pre alpha release really isn't newsworthy. Is this some one's pet project? I wasn't aware Python was broken.
Thalasar
Sounds like a korean car.
Watch this Heartland Institute video
call it "Industrial-Strength" if it's "pre-alpha?"
All Your Memory Are Belong To Java
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
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?
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...
This is taken from the Prothon Description
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 ??
I hear there's rumors on the Slashdots
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.
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?
They would if it wasn't easier to do in python.
kyjello is too damn smooth to make a signature.
http://www.iolanguage.com/
-... ---
Found a little example code inside the tarball, that shows what they mean by no classes:
.name = ""
.__init__(name): .name = name .hello() .
.hello(): .name
Emp_proto = Object()
with Emp_proto:
def
return
def
print "My name is:",
Emp_proto.hello()
emp = Emp_proto("Jim")
emp.hello()
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
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 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.
Chr0m0Dr0m!C
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.
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.
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.
Everybody's a libertarian 'till their neighbour's becomes a crack house.
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".
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
Not improved - just as bad:
..."
"Like Python, Prothon uses indentation
Oh joy.
THL.
Keeping
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 without upgrading their knowledge, would you?
Instead, start from places like the ALU web site or Cliki or Paul Graham's Lisp FAQ.
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 by doing this, so be forwarned.
To a Lisp hacker, XML is S-expressions in drag.
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: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: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.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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.
Buy Text Processing in Python
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:
(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>
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.