Sign in to follow this  
qpingu

New programming language

Recommended Posts

I'll keep this short and to the point. I've been working on a new programming language (based on Java) and I just want to see if anybody is particularly desperate for a certain feature. That's all. I can't reveal what I've done thus far, but the suggestions would be fantastic and could go a long way. Thanks.

Share this post


Link to post
Share on other sites
Ruby was developed some 15 years ago. It has only now taken off and proven its usefulness. And Ruby was based off lessons from Lisp and Smalltalk.

Therefore, don't hide your language like it's next world dominating paradigm. It's not. The sooner you open it and have people using it and commenting on it, the sooner you'll see what to focus on.

As for suggestions? You didn't even mention if your language is imperative or functional. Or perhaps it's logical. What does it currently support?

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
Ruby was developed some 15 years ago. It has only now taken off and proven its usefulness. And Ruby was based off lessons from Lisp and Smalltalk.

Therefore, don't hide your language like it's next world dominating paradigm. It's not. The sooner you open it and have people using it and commenting on it, the sooner you'll see what to focus on.

As for suggestions? You didn't even mention if your language is imperative or functional. Or perhaps it's logical. What does it currently support?


Yes he did. He said its based on java. perhaps that is more of a hint tho.

p.s. i agree

Share this post


Link to post
Share on other sites
My best suggestion would be to make it as little like java as you can. Other then that, powerful macro functionality (akin to lisp) goes along way.

Indy

Share this post


Link to post
Share on other sites
Thoughts of the day:

If your language doesn't support first class functions or at least some half-assed implementation like .NET delegates I will promptly and unconditionally ignore it.

If you do not supply 'string+string' (or similar convenience stuff like Java doesn't) I will probably ignore it unless there's a good reason or you're doing something else cool.

If your language tries to do as much as possible in one line (often by making things into obscure operators) I will beat you with a stick.

If your language requires syntactically meaningful whitespace I will beat you with a stick.

Share this post


Link to post
Share on other sites
First class functions with short and pretty syntax.
Lexical scoping (and closures).
Variants and pattern matching (see Haxe's enum/switch construct, but make matching recursive please).
A good type system (no primitives like 'int', everything should be classes/interfaces).
Consistency in naming (no size() vs. getLength() - it's wrong in multiple ways).
Orthogonality in features (no "properties" if there are methods, and no fields if there is lexical scoping and methods).
Automatic memory management.
Deterministic resource disposal for critical stuff (see C#'s "using" or do something with closures).
No NULL! Or at least, no nulls by default.
Local type inference.

I don't care much for whitespace, but readability and consistency is important. Having to write "public static final" ten times is however just redundant verbosity.

And that's all I can rant today. Look at Scala, it has half of these features (plus a lot that I didn't mention), is Java-like and is a pretty decent language.

Share this post


Link to post
Share on other sites
crappy delegates are C# not .NET. I hate them too.

but other .NET languages like Nemerle and F# have proper support for closures and first class function. The difference is akin to that between digging with a bulldozer or a broken shovel.

Share this post


Link to post
Share on other sites
Quote:
Original post by Daerax
crappy delegates are C# not .NET. I hate them too.

but other .NET languages like Nemerle and F# have proper support for closures and first class function. The difference is akin to that between digging with a bulldozer or a broken shovel.


True true. Though I'm not sure how the F# FastFunc things exist as .NET types compared to System.Delegate; haven't gotten that far yet.

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
Quote:
Original post by Daerax
crappy delegates are C# not .NET. I hate them too.

but other .NET languages like Nemerle and F# have proper support for closures and first class function. The difference is akin to that between digging with a bulldozer or a broken shovel.


True true. Though I'm not sure how the F# FastFunc things exist as .NET types compared to System.Delegate; haven't gotten that far yet.


Oh i c what you mean. .NET doesnt inherently support functions as types, F# ones are implemented in terms of regular classes and generics.

but then neither does the processor. having too much built in support in your framework makes it bulky and unweildy, better to have a general but powerfully flexible set of building blocks.

Share this post


Link to post
Share on other sites
Quote:
Original post by Daerax
Quote:
Original post by Telastyn
Quote:
Original post by Daerax
crappy delegates are C# not .NET. I hate them too.

but other .NET languages like Nemerle and F# have proper support for closures and first class function. The difference is akin to that between digging with a bulldozer or a broken shovel.


True true. Though I'm not sure how the F# FastFunc things exist as .NET types compared to System.Delegate; haven't gotten that far yet.


Oh i c what you mean. .NET doesnt inherently support functions as types, F# ones are implemented in terms of regular classes and generics.

but then neither does the processor. having too much built in support in your framework makes it bulky and unweildy, better to have a general but powerfully flexible set of building blocks.


First of all, the processor supports jack squat, especially not classes. Integers and floats at most. It's not a valid argument for not supporting first class functions.

What few but powerful building blocks are you talking about?

Share this post


Link to post
Share on other sites
Quote:
Original post by Ahnfelt
Quote:
Original post by Daerax
Quote:
Original post by Telastyn
Quote:
Original post by Daerax
crappy delegates are C# not .NET. I hate them too.

but other .NET languages like Nemerle and F# have proper support for closures and first class function. The difference is akin to that between digging with a bulldozer or a broken shovel.


True true. Though I'm not sure how the F# FastFunc things exist as .NET types compared to System.Delegate; haven't gotten that far yet.


Oh i c what you mean. .NET doesnt inherently support functions as types, F# ones are implemented in terms of regular classes and generics.

but then neither does the processor. having too much built in support in your framework makes it bulky and unweildy, better to have a general but powerfully flexible set of building blocks.


First of all, the processor supports jack squat, especially not classes. Integers and floats at most. It's not a valid argument for not supporting first class functions.

What few but powerful building blocks are you talking about?


exactly. programming languages are just abstractions. Its an onion philosophy. Id rather the framework be able to support functions first class than it be built in explicitly. The languages i use on .net give me that, i dont care if its not supported by .net inherently - its not supported by the computer inherently either - the languages themselves do though and they do it fast. With simple but flexible base more can be accomplished is my point.

we want a framework that is useable to all language designers not just functional people. and for whatever reason untyped or dynamic languages are all the rage now. So its give and take really not everyone will be satisfied. .NET platform is currently not the most ideal for functional programming but its failings do not begin to compare to what it is offering.

Share this post


Link to post
Share on other sites

  • Pattern matching

  • Built in Either and Bignum types

  • Type inference

  • First class functions

  • Currying



are all things I miss being provided 'natively' (i.e. with little to no extra work on my part).

Share this post


Link to post
Share on other sites
Currying is probably the least useful, most confusing thing I have ever seen. I looked over some of my Haskell code from a class last term, and I can't tell what the hell it's supposed to do. Maybe it's because I started programming in qBASIC...

Share this post


Link to post
Share on other sites
Quote:
Original post by steven katic
RE: crappy delegates are C# not .NET. I hate them too.

false, false. crappy delegates: can be used in VB, C++, C#,....
..are widely used in .Net Framework


those are languages not the cli.

i too think currying is over hyped.

Share this post


Link to post
Share on other sites
We can't really make suggestions if we know nothing about your language, but here are some of the things I've been personally thinking about lately:

* Make everything a first-class object. Everything. If your language has a name for it, you should be able to pass it as a function argument.

* Dependent types. They're largely stuck in the world of theory at the moment, but anyone who could implement them in a practical way would be doing a great service to the field of programming language research.

Share this post


Link to post
Share on other sites

if you havent already seen it, scala is a language which takes advantage of the java runtime and library api's but includes a lot of functional goodness (guards, pattern matching, partial application) as well as catering to object orientated approaches.

I havent played with it myself (i am still trying to wrap my head around functional programming generally) but there's an easy to watch video here introducing the design justifications and summarising the functionality which i have seen a couple of times.

http://video.google.com.au/videoplay?docid=553859542692229789&q=scala&total=5849&start=0&num=10&so=0&type=search&plindex=1

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
Quote:
Original post by Daerax
i too think currying is over hyped.

I am not that familiar with Haskell, but what advantages does the currying support offer over the currying-through-closures offered by functional languages?


Well Haskell supports closures and currying and partial application all. As i understand it, currying is merely stringing out a function which takes multiple values and representing it as a series of single i.e. non tupled inputs function. That is all. This is really merely a mathematical concept. with currying partial application becomes a very powerful tool where one passes a function less parameters than it takes and gets a function in return. this can then be used later for some appropriately obscure bit of coding. a bit of mixing and matching across functions and parameters. used properly, its one way to get some of the succinct code functional programming is famous for. sometimes i think people mean partial application when they say currying.

closures are kinda similar but in a dual kind of way. they basically allow one to carry values across scope. well, within nested functions that is - even when the host function has long since exited the nested function may still access variables of the hosting function. sometimes this is useful. on .net i have found this useful for dynamic events.

Share this post


Link to post
Share on other sites
Does anyone else feel that java with its derivation based event handling mechanism seems completely deficient compared with the use of c# delegates (a kind of a partial application).

A delegate as a partial binding of a method just feels so clean and decoupled to me. the only coupling implied is through the typing of the function signature and it is so simple to route control to where you want it without having to go through the mess of deriving in an event handling interface and then overidding a virtual.

I know that there is an unresolved problem in NET whereby a delegate binding an object's method is a strong reference so that event handlers will keep an observer object alive and kept from gc cleanup (could be useful in specific circumstances but not in the general case). But the underlying principle feels so correct compared with the java contortions. Its not a really strong criticism since c++ kind of has a similar problem whereby boost::bind can natively use shared_ptr (strong reference) but not weak_ptr's without modification and haskell i suppose is the same as the net gc if partially applied functions were used as event handlers with a monadic io event stream.

I have only used java in courses and i mostly have forgotten it so please forgive if ive got any of this wrong but i find it funny and weird to think how the language and its api's will be able to survive when this side of things has been got wrong by sun in such a fundamental way. maybe my sense and proportion is exaggerated but java event stuff just doesnt feel right at all.

Share this post


Link to post
Share on other sites
Quote:
Original post by chairthrower
Does anyone else feel that java with its derivation based event handling mechanism seems completely deficient compared with the use of c# delegates (a kind of a partial application).


No, it's just a different method.

And Java supports delegates perfectly fine via anonymous classes. Eclipse framework, and some Swing/AWT uses this concept to great extent. It's just the syntax that is verbose. Then again, everything about Java is verbose.

Outside of syntactic details however, approaches are semantically identical, except that Java's may be more pedantic about type-safety.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this