Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Open Source Programming Language Design

krow posted more than 13 years ago | from the more-languages-should-look-like-LISP dept.

Programming 243

descubes writes: "It's been a long time since Java, the last major change in programming languages. Could the next one be designed "the Open Source Way"? For a few years, I have been working on a programming language called LX, which is part of a larger system called Mozart. I need some feedback. Could Slashdot readers comment on which programming language features they would like?"

cancel ×


Sorry! There are no comments related to the filter you selected.

#!/usr/bin/perl (1)

Anonymous Coward | more than 13 years ago | (#260295)

if it cant be done in perl, then i dont want to do it. seriously though i think what makes perl so loved is its ability to parse like mad and to interact with other languages so easily. keep both of these in mind and i think you will be on the right track IMHO

Re:Modula3 (1)

Anonymous Coward | more than 13 years ago | (#260296)

Oh yes Christophe, please add this !
From your friendly Dylan-loving friend in 42 :-) (This is a private joke I know descubes/Christophe from work)

Indeed LX has some the elements of Dylan in it:

  • Multimethods
  • Non-unwinding exceptions
  • Modules in-language

Now if you could add multiple return values... Ah if only we had them in C. Well C0X maybe, I can dream.

Re:Bases (1)

Anonymous Coward | more than 13 years ago | (#260297)

All your common base are belong to us.

Re:What is your goal with the language? (1)

Anonymous Coward | more than 13 years ago | (#260298)


Eiffel does not have excellent tools. Ebench in particular is a festering piece of crap.

No offense.

<Insert-deity>-damn indentation-sensitive stx (2)

Anonymous Coward | more than 13 years ago | (#260308)

The whole thing is brain-dead. And my biggest peeve? Indendation-sensitive syntax.

Do any of these idiot-child language "inventors" ever think about how indentation-sensitive syntax impacts a good cut and paste job?

And no, you idiots out there who are cranking up the whine-o-grams: "but George, shouldn't you be writing modular & re-usable code instead of cutting and pasting?"

No! Goddamnit, I'm talking about when real work get's done. When you are writing real code while learning about a complex problem, and you have to re-design 2-6 times a day. That is when real men & womyn cut and paste.

Then again, the only languages with indentation-sensitive syntax are prissy little scripting languages, so I guess real programmers need not apply.

Uh, then again, there could be "real" languages out there with indentation-sensitive syntax, Lisp? Never used it myself. Some functional languages used in CS classes of yore? Don't recall. I didn't claim to know everything *and* be perfect.


Re:Define a problem domain for your language (2)

Anonymous Coward | more than 13 years ago | (#260309)

Compilers produce crappy assembly language

Yes. HOWEVER, assembler code is not 'magically' faster than C code. A bad Assembler programmer's code will run slower than a good C programmer's code, and vice versa. However, a good assembler programmer's code will run faster than a good C programmer's code, most of the time.

However, this point will be moot when Sun begins the trend of making up for a slow and inefficient language by producing hardware specifically designed for the language: the Java processor board. It plugs in like a standard IDE/PCI/whatever board, and it runs Java bytecode at blazing speeds.

Don't forget the curse of PL/I (4)

Anonymous Coward | more than 13 years ago | (#260310)

A very long time ago, IBM tried to combine Fortran, COBOL, and a mess of other languages into an uber-language. They tried to put every feature in, and it got so big and cumbersome that it never became widely adopted. Putting a "request for features" call out to the world will surely never give you the language you're striving for. If Python, Java, Rebol, Perl, C/C++, etc. don't solve your problems, figure out what you're missing and take it from there.

What I'd like to see. (5)

Anonymous Coward | more than 13 years ago | (#260311)

Things I'd like to see:
  • Compiled and Interpreted (interpreted for development but a compiler for what needs speed just like some people use C interpreters to develop C apps)
  • A good standard library (like Java/Python/Perl)
  • Perhaps Truly Object Oriented (like Smalltalk)
  • Support flexibility, like I'm annoyed by Java when you can't create references to methods... it'd be very useful in a great many projects I do..

The key is to be unique, you'll notice Python and recently rose to fame in that it contained ideas not seen in mainstream lately, such as tabs for delimeters of the score. Try to come up with someone radical that most people can't even think of now, but keep it simple so people can use.


The Man (684) | more than 13 years ago | (#260315)

...You need to have COME FROM, gotos are for wussies who need their hands held...

Oh, you mean exceptions. After all,

try {
} catch (SomeExceptionType baz) {

(This text is here in an effort to prevent this post from being considered filled with junk and rejected. Please ignore it and bitch to CowboyNeal that his "lameness filter" fails to catch first ports, hot grits, all your base, and natalie portman garbage but somehow rejects this perfectly valid and even fairly on-topic post. Thanks for nothing, CowboyNeal.)

is really no different from

if (some_condition)

At least Intercal folks realize their language is a joke, I don't think Sun have caught on yet.

Re:Jikes (5)

pohl (872) | more than 13 years ago | (#260316)

There should be a "Misinformative" moderation label. Jikes is not an open source variant of Java. It is a compiler for the Java language, implemented with an open source license. It is merely an alternative to the javac compiler that comes with the JSDK. It was even a faster alternative the last time that I tried it, but it is not a language that was designed in an open community, which is what the question is about. One could use "offtopic", I guess, but then would likely be screwed in metamod. Not that I care about karma.

Define a problem domain for your language (5)

ciurana (2603) | more than 13 years ago | (#260323)

Congratulations on your development of LX. It seems like you've made excellent progress so far, and the language definition and examples are useful for understanding the language itself. It looks cool.

Rather than commenting on the language and its features, I'd suggest that you identify a problem domain where your language (and Mozart) are a better solution than any other options out there. This will allow users to identify your language more quickly and bring more users to it. When people think of Java they think "the language of the web." PERL? "The duct tape of the Internet." I'm sure you get the idea.



Re:whatever it happens to be.. (2)

S. Allen (5756) | more than 13 years ago | (#260325)

but you're ok with having to download a compiler? or do youalso demand that it also compiles with gcc automatically?

Re:Define a problem domain for your language (5)

Goonie (8651) | more than 13 years ago | (#260327)

From my undergraduate-level compiler design course (which every CS person should take, IMHO), there are many problems in optimizing compilers that are NP-complete. For instance, the favoured method of allocating variables to registers is NP-hard for exact answers, but a heuristic is used that works very well, provided you have more than about 16 registers (one of the main reasons why modern architectures all have 32 or more registers).

Anyway, there is no such thing as the "perfect optimizing compiler". To be verifiably optimal, as well as knowing everything there is to know about the machine's internal architecture, it would have to have complete knowledge about the dataset that the program to be compiled is to be run on - if that is not available, if there is a tradeoff to be made the compiler has to make a choice that will be suboptimal

To take a simple example, the compiler might choose functions to be placed in a certain order in the object file so that functions called repeatedly in sequence can all fit in the cache at once. Running the program with a different dataset could produce different call patterns, and thus the optimal layout of functions in the object file might be different.

So, your program, and any non-trivial program, could only ever be truly "optimized" for one input dataset. Anything else is a compromise.

Go you big red fire engine!

Java? Duh? And the minimalist approach (1)

dido (9125) | more than 13 years ago | (#260328)

Java did not really introduce any major innovations in programming language design, at least not anything that was not already present in many other programming languages. Java is actually C++ on a diet, which is also bytecode interpreted to provide what Sun thought would be platform-independence, but in reality it made very slow code. Try using the Java and C++ versions of the Xerces and Xalan XML and XSLT parsers available from the Apache XML project [] to do the same thing, such as convert even a small DocBook document into HTML with an appropriate set of XSL stylesheets. The difference is striking. (in my case, I have no choice, because there is no non-Java, Free [speech] XSL Formatting objects converter with functionality comparable to FOP, which is not only in Java but depends on the Java versions of Xerces and Xalan)

As for what one feature I'd like to see for new programming languages is CLEAN DESIGN. I like the way R^4RS Scheme document put it: "Programming languages should not be designed by piling feature on feature, but by removing the weaknesses and restrictions that make additional features seem necessary." It seems that most languages that have existed primarily as open source projects and even many standardized languages wind up doing precisely the opposite, piling features that seem necessary but could be better be served by extending what features are already there to make the features unnecessary. What I'd like to see is an object-oriented or imperative language that tries to emulate Scheme's philosophy: the attainment of perfection by finding the point where there is nothing more that can be taken away.

whatever it happens to be.. (1)

dwlemon (11672) | more than 13 years ago | (#260331)

If I have to download a special interpreter or virtual machine to use it, then I'm not even going to look at it.

Re:It needs to enforce modularity! (1)

HeghmoH (13204) | more than 13 years ago | (#260332)

Excuse me, but there are about six billion languages out there that actually do OO in a decent way (as opposed to C++), and do everything you're talking about. Why complain when you can just switch to something that works?

Mainstream influence of Functional Languages (5)

alienmole (15522) | more than 13 years ago | (#260336)

Functional languages have already had quite a strong impact on mainstream languages, but only indirectly. Your professor is absolutely right about how long it takes for programming ideas to hit the mainstream. Java is the first example of a mainstream language which allows some of what Smalltalk enabled back around 1972.

However, Java focuses almost exclusively on strongly-typed object-orientiation as its primary concept. It completely ignores two related features which make Smalltalk powerful: code blocks and closures. These Smalltalk features were actually derived from LISP, which at the time (1972) could only be called a proto-functional language. The first truly functional language was probably Scheme, in 1975.

Because the functional ideas inherent in LISP were not fully developed at the time Smalltalk was created, the conceptual emphasis in Smalltalk was on object-orientation, derived from Simula. If Smalltalk had been able to draw from Scheme instead of LISP, there's a strong chance that it would have had a more functional bent, which might have affected the languages which were influenced by Smalltalk.

Instead, Scheme came along just a little too late to directly influence the mainstream. Only recently have we started to see functional features appearing in mainstream languages. PERL and Javascript both support lambda-calculus-compliant closures, and first-class procedures, which are fully realized incarnations of the original concepts on which Smalltalk's somewhat limited code blocks and closures were based. Python has also recently moved in this direction.

I predict that functional features will slowly be adopted by most mainstream languages over the next decade or two. Java will be the last new mainstream language that's completely non-functional (pun intended). The power of these functional capabilities is too great for language designers to ignore.

Note that I'm not saying that current functional languages will become mainstream languages. Rather, just as mainstream languages have absorbed object-oriented concepts, they will also absorb functional concepts.

Anyone writing a language today who isn't familiar with Scheme, Haskell, and ML may as well throw in the towel right now. Unless they plan to invent the next great paradigm, they will not succeed. I think it's impossible, in 2001, to write a language without taking functional concepts into account. (Of course I'm reminded of Tanenbaum telling Torvalds that writing a monolithic OS kernel in 1991 was a fundamentally bad idea...)

Oooo! Oooo! I want... (5)

Jerf (17166) | more than 13 years ago | (#260339)

I want it to be object oriented!... except for the useles parts. Oh, and combine the best of imperative and functional, the best of perl and python, the best of C++ and smalltalk, the best of capabilities and UNIX, the best of BeOS and OSX, the best of nethack and Angband, and the kitchen sink.

It should be work on Palm Pilots, and Beowolf clusters. It should be easy to extend, easy to parrellize, and easy to optimize for every major processor currently in use. It should be easy to read, have a powerful and compact syntax, familar to people who understand Pascal, Ada, LISP, Prolog, or SQL. It should be comprehensible to an advanced two-year old, usable for teaching computer science concepts in college, and usable in a professional environment. It should be loved by both the Slashdot community and Microsoft, and it should be immune to embrace-and-extend.

It needs to perfectly fit my needs but also perfectly fit the needs of my grandmother. It should have a dancing baby as a atomic object. By the way, whatever your language is currently doing is totally wrong, and you should totally change it around. Also, you need to satisfy every last comment posted in response to this article, plus the ones people only thought, but didn't take the time to post.

Your language should replace OpenGL as the dominant graphics platform. Your language should have an order-N searching algorithm built in. Your language should easily extend into the quantum domain when such computers become available. There should be a command-line option that will read in all of my old QuickBasic programs from when I used DOS.

Your language should be interpreted, compiled to byte-code, compiled to Java(tm) byte-code, or compiled to native code, depending on context. Your language should make sure that all programs written with it should be optimally thread-safe. Your program should be able to detect whether a given program will go into an infinite loop. Your language should have no patent issues. Your language should have all the whiz-bang features other languages have.

I want to be able to apply an XSL stylesheet to my source code and get the equivalent program in Turing Machine code, but I don't want to learn XML... that's too much to ask. Your language should automatically internationalize all programs written in it.

Your language should be elegant. I want to be able to implement the Linux kernel in three lines of code.

I would take any suggestions on Slashdot with a Detroit-salt-mine-sized grain of salt. Consult a real language expert.... because most of all, your language should not designed by a committee of random computer users.

Great languages come about to solve real problems (5)

JohnZed (20191) | more than 13 years ago | (#260341)

When developers (Pike + friends) needed an efficient, processor-independent language for systems programming, they created C. Later, when the systems got so huge that they needed a new layer of abstraction, they (Stroustrup et al) looked at the problem and came up with C++.

Guido wanted a language with the readability of ABC, but with exceptions, OOP, and extensibity, while Larry Wall obviously needed a Postmodern Extension and Reporting Language. Java's history is similarly tied in with very specific problems (smart devices, then applets).

A programming language is an answer. If you propose to design one without first asking a concrete question (no, it doesn't count if your question is "what would be a really cool language?"), I suggest that you name it "42" for obvious reasons.


Re:What nobody else wants (or will say)... (1)

lytles (24756) | more than 13 years ago | (#260342)

just want to agree for the most part. a little long overall, but some great lines (oo cocked :) and just hearing someone stress the importance of being able to understand the hardware and software at once (without substantially more effort than the one) feels good.

i don't really get the need for lines vs. characters, but then i'm a c bigot.


Re:Straight jacket vs. control (5)

gunter (32474) | more than 13 years ago | (#260344)

"I like Java because no matter what I do I can't do anything dangerous. Err wait, I hate that about it :)."

Our resucue here is JNI. With this you can even segfault java :)

Re:Bases (1)

descubes (35093) | more than 13 years ago | (#260346)

To be slightly less snide for a moment, what I'm trying to point out is that, while this is a good idea, it is slightly silly and slightly unnecessary. There are certain bases that are used... there are others that, in general, are not.

This is a computer scientist's point of view. Computer users generally use bases which are powers of 2. Some mathematical problems, however, are best expressed in other bases. Hence the capability to use arbitrary bases in LX... including for floating-point.

Don't support every base through a clumsy yet silly syntax. I'd rather be able to do the following, and only the following: 10, 10d, 12o, 0Ah, 1010b

I agree with the "I'd rather be able to", and I will consider adding support for a notation like this. On the other hand, I disagree with the "only" part.

Re:#!/usr/bin/perl (1)

descubes (35093) | more than 13 years ago | (#260347)

LX is not intended as a scripting language. Not that I don't like Perl, but it's a different problem space...

Could you illustrate why you would need RE support in the language (as opposed to in the library, where RE support already exists in many languages, including C)?

Re:Define a problem domain for your language (1)

descubes (35093) | more than 13 years ago | (#260348)

What about: LX and Mozart are a better solution than any other option out there for any application? OK, I was being biased. What about: any large-scale application where performance and stability matter?

When C started, a big application was 8K of code, and the problem was writing compact code. Today, a small one is 8MB, and the problem is "how do I stay up for days in a row", or "if I get a TLB miss here, performance degrades by 200%"... That's what I am trying to solve.

Without the faith, I would not do this :-)

Re:My thoughts... (2)

descubes (35093) | more than 13 years ago | (#260368)

Expression reduction. This seems like it would be hard to implement and very confusing.[...] I think it creates too much confusion unless you can demonstrate that this would be a huge speed boost.

I did actually implement it :-) Checkout the compiler from CVS... The precise rules are written in a separate document (which I need to put on the web someday), but basically amount to "the largest that matches." People who have worked for instance on large matrices or vectors that thrash your TLB know that there is a significant speedup in combining. Well, even multimedia encoding/decoding would benefit: this is the right way to define at a high level the equivalent of low-level instructions like MMX, AltiVec, etc. But the most important readability gain in my opinion is for types (think "array [A..B] of C" being a type expression.)

The first example you showed of these was basically using them as a replacement for unions. I hate unions.

The fact that you hate them doesn't make them useless. Consider a device control register where flipping a bit in one register changes the meaning of another register. The alternative is ugly pointers.

Basically, you created much simpler syntax for dynamic memory management.

No, I tried to create a way to represent data types that you can't represent easily in C. Simple application example: Run Length Encoding (RLE) for your good old BMP files.

I can't help but see so many different types of pointers as needlessly complicated and confusing. What will you really be needing pointers for?

Two answers there. First, the existence of multiple pointer types is a consequence of having them defined "in the library" rather than "in the compiler." Any program can define a "pointer type." And all the pointer types I describe are in the library.

Second, I essentially try to fix a problem in C, C++, etc, where a pointer to allocated memory automatically can 'alias' an object on the stack. That's very bad for optimizations. This doesn't happen in LX because these would be pointers of different types.

Last, to answer your suggestion of "leaving the others out", since the language allows you to create them, if there is no library-defined pointer, alternatives will pop up (just like the many string classes at the beginning of C++)

I think you are misinterpreting where the (fragile base class) problem lies

The fragile base class problem is that you cannot extend the class. I am suggesting that the set of polymorphic operations on a type is not closed by a single definition (for C++, the class definition.) Hence, any derived class can first add the functionality to its base class if needed. A bit as if in C++ you could say:

class Foo extension {
virtual void MyNewMember();

class Bar : Foo {
// Can now use MyNewMember.

void Foo::myNewMember() {
// extends class Foo only for class Bar.

Thanks for the comments. They help.

Re:Interesting (2)

descubes (35093) | more than 13 years ago | (#260369)

LISP is cool, no doubt. And yes, it is reflective, user-built, user-extensible. On the other hand, it was never a language for the rest of us. One of the reasons is: Lots of Insipid and Stupid Parentheses. LISP is a bit like the Reverse Polish Notation in HP calculators. If you know how to use it, it's really great. But most people can't get used to it.

And yes, I sometime uses LISP or other functional languages. Heck - early versions of LX even had support for Prolog-style backtracking! But no, Common Lisp does not have 33 out of the 38 features, and no, 38 - 33 is not 4 :-)

Bases (5)

addaon (41825) | more than 13 years ago | (#260373)

From the webpage:

integer Large := 16#FFFF_FFFF
integer Twenty_Seven := 3#1000
real MAX_FLT is 2#1.1111_1111_1111_1111_1111_1111#E127

If I can choose a base arbitrarily, why the assumption that I want to choose my base in base 10? Why can't I choose my base in base 16, as such...

integer thirtytwo = 16#20#10

But then I still need to choose the base I want to choose my base in in base ten... why not

integer thirtytwo = 2#10000#20#10

But then... agh! We're stuck in a loop.

To be slightly less snide for a moment, what I'm trying to point out is that, while this is a good idea, it is slightly silly and slightly unnecessary. There are certain bases that are used... there are others that, in general, are not. Don't support every base through a clumsy yet silly syntax. I'd rather be able to do the following, and only the following:

integer ten = 10
integer ten = 10d
integer ten = 12o
integer ten = 0Ah
integer ten = 1010b

where the default encoding is decimal, but I can use one of d, o, h, or b to switch to another common base.

Re:Define a problem domain for your language (4)

MustardMan (52102) | more than 13 years ago | (#260385)

C? The retarded horse with a gimpy leg. You wanna shoot the damn thing so bad, but I'll be damned if the sonofabitch can't still get up and run at a decent gallop now and then, when you take a good cattle prod to its ass

Re:Define a problem domain for your language (1)

1010011010 (53039) | more than 13 years ago | (#260389)

C? The retarded horse with a gimpy leg.

Why do you say that?

- - - - -

Re:What I'd like to see. (2)

1010011010 (53039) | more than 13 years ago | (#260390)

Can you (or someone) post a list of interesting and/or good C interpreters?

- - - - -

Re:Interesting (1)

Oniros (53181) | more than 13 years ago | (#260392)

Yeah, I prefer Scheme to LISP too, much cleaner. And the reference manual is like 50 pages, yet the expression power is amazing.

As for a good Scheme compiler:

hasn't everyone designed a paper language? (1)

eric17 (53263) | more than 13 years ago | (#260393)

Mine currently exists on 30 or so sheets of 'em.
Some high points:

- a focus on efficiency, avoiding problems that other languages have and keeping a C-ish flavor (even less than Java, but it's there).
- declarations and definitions together a la java, although they can be split among several files.
- cooroutine-ish "iterators" a la Sather, but nicer syntax. <- check this out in Sather, it's a really cool idea. In fact this is the only way to perform a loop in the language.
- a novel "if" statement that can perform the work of "switch", as well as produce a value. It's not the franken-if you are imagining...or maybe it is.
- a unified way to annotate language elements with declarative statements.
- both callers and callees declare whether arguments are read-only, possibly modified, or created.
- be able to specify different heaps for objects on an algorithm basis, allowing garbage collection to be optimized on an algorithmic basis.
- Cross-sectional or "aspect-oriented" declarations. For example, be able to describe what is to be done at the end of each method in class X,Y and Z, but specify this in just one place.
- well defined base types and core libraries for portability (but no virtual machine!)
- Design by contract declarations a la eiffel.
- first class functions (like C/C++ functions)
- parameterized classes.
- portable distribution format (something like a compressed abstract syntax tree and any number of other resources in a zip file)
- case insensitive identifiers.
- only one comment marker: // (if that's not good enough, get a better editor! :)
- module import specifications not in code source files, but in the specification for the link-unit, allowing mapping, replacement, and less specification in total.
- types separate from classes. Similiar to Java's interfaces, but implementations can be reused too.
- global analysis to automatically determine polymorphic methods, dead code and make profile driven optimization a bit easier.
- objects can be allocated on the stack like C++.
- very little is done behind your back--no hidden conversions, compiler written invisible routines, etc.

Re:What is your goal with the language? (2)

eric17 (53263) | more than 13 years ago | (#260394)

Perl is better in its niche than any other alternative, had free implementations from the start, and isn't a growth on the pascal-like language tree.

When programs were small, and machines were slow, Eiffel was great for fast machines and big programs. Now that programs are big, and machines are fast, it has a niche. But the best implementation is proprietary, and it's always going to be a growth on the pascal-like language tree.

Your organic versus designed argument holds no water. What about the popularity of Java? What about the non-popularity of Forth? It's not how it came about, it's how it does the job.

Oberon already encourages open source (1)

Rares Marian (83629) | more than 13 years ago | (#260400)

Out.String("Hello World");
END Hello

There's no main(). Anything can be a library, a program, a data file, or source code.

Oberon just has no corporate backing.

Re:Modula3 (1)

Rares Marian (83629) | more than 13 years ago | (#260401)

Just pass by reference and return nothing.

change? (1)

Alban (86010) | more than 13 years ago | (#260402)

It's been a long time since Java, the last major change in programming languages.
How exactly is Java a major change in programming languages? I mean to me, it really ressembles Modula3 and pascal _a lot_ (much more so then C++). I don't really consider it a major change in programming languages except that there is a powerful company behind it with tons of programmers supplying a huge number of basic packages (which is really cool). Plus suns markets the language like a language has never been marketed before. Anyway all this to say... what's really new about it?

Re:It needs to enforce modularity! (1)

emmons (94632) | more than 13 years ago | (#260406)

That's not a programming language problem, that's a lazy programmers problem.


Re:What I'd like to see. (3)

Fjord (99230) | more than 13 years ago | (#260407)

I'm annoyed by Java when you can't create references to methods

Object o=new Object(); java.lang.reflect.Method hashcode=o.getClass().getDeclaredMethod("hashCode" ,new Class[0]); Integer hc=(Integer)hashcode.invoke(o,new Object[0]); System.out.println(hc);

Now you try.

Re:#!/usr/bin/perl (2)

notsoanonymouscoward (102492) | more than 13 years ago | (#260409)

Here here!

For a language to be useful for many tasks, it really needs good regular expression support.

Not just for the RE stuff mind you, but I'd look to PERL as an example of a number of good programming language design practices in action. I especially like perl's ease of extensibilty. There are so many modules out there it boggles the mind :)

Why the grail fight yet again? (5)

BlackStar (106064) | more than 13 years ago | (#260411)

There goes a few moderator points down the toilet. I was hoping SOMEONE who might have wandered through MIT would have put up a contrarian point of view to the whole "best thing" idea in languages. If one did, I can't find it.

WHY does everyone have a favourite language, and assume it's the cat's PJs for every problem under the sun?

I use, primarily, Java. Why? Because for what I do, I need the portability, and it's more than fast enough, and yes, the recent versions are portable properly. They're also likely a lot faster than you think they are.

But my real point, is that it's not the only language, and the reference to MIT is found early in the book Structure and Interpretation of Computer Programs by Abelson, Sussman and Sussman. I myself did not go to MIT, so if I mess up, don't blame them, but the point made in the book is thus:

"... First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. ... Second, we believe that the essential material to be addressed by a subject at this level is not the syntax of particular programming-language constructs ... but rather the techniques used to control the intellectual complexity of large software systems."
Different languages evolve to solve different problems. People don't build things like Simula for writing a network driver or the next 1st person shooter. They build it to solve complex, physical simulations. The expressive power is greatly increased, but the problem domain is restricted.

A general language is a nice idea, but we're starting to need something beyond that. The whole idea of the project is actually meta-programming. Not writing your next device driver. Write it in C. Maybe C++ if you must. But the OOP languages have given us a large number of very reusable, efficient components, regardless of what detractors of the OOP approach itself may claim. Knitting those components together right now is tedious in C++, Java, VB or even many of the visual designers. We're still bolting rods to wheels, instead of expressing the transfer of linear force to rotation at a higher level.

I would humbly suggest that all the crock about the syntax and such be backed off. Especially type constructs, object aspects, and the other things addressed quite well in many different ways by other 3GLs.

Start with interfaces. Describe the interfaces, and describe the use of an object that adheres to those interfaces. From there, find ways of describing systems of those interactions.

Contrived example (required): database connector, table model, grid component, graph component, statistical analysis tool. Each has certain interfaces that can connect to each other singly or in groups, and can control things singly or in groups. The old MVC writ large. Find a way to describe and program the MVC system at the MVC level.

I wish I had any idea how to do this, but I don't. I write in C, C++, Java, Perl, and have dabbled in everything from assembly up to Scheme. It's all so similar in far too many ways. It's not ideas and systems, it's still bits and branches.

Many posters argue the efficiency. Your points are valid, but large, complex systems spend tens or hundreds of millions of dollars in programmer time for software running on "mere" millions of dollars of hardware. Doubling the amount of hardware and halving the amount of programming is a WIN for all involved.

Odds are that the approach of the project is already correct. It uses a 3GL as the "worker" bits (Java, in this case, fight about it somewhere else), and tries to put a true meta-layer on top of that.

The concept is as foreign to working programmers today as it could be. It's like knowing Classical Greek physics only, and getting hit by Relativity and being asked to design the analysis tools for it. You don't even know Newtonian theory yet. There is that large a jump in there.

So skip the bits about the next cool language. It's a valid discussion, but unless I miss my mark, this project is grasping at something far, far beyond that. And being able to code to a pointer doesn't really matter at that level.

Design by committee (2)

Michael Woodhams (112247) | more than 13 years ago | (#260414)

If you design your language by committee, you'll end up with something like Ada. (OK, I've never even seen Ada code, but I've never heard anyone say anything good about it.) If you just let everyone glob in features from their favourite languages, you'll end up with a monstrosity that nobody ever uses, like Perl. (Um, hang on ...)

Re:Interesting (1)

ericdano (113424) | more than 13 years ago | (#260415)

very astute!

What Are You Trying to Accomplish? (1)

smack.addict (116174) | more than 13 years ago | (#260416)

The point of this whole endeavor is exactly what?

My thoughts... (4)

slamb (119285) | more than 13 years ago | (#260418)

Here's some things I do like:

  • Indentation-sensitive syntax. I've seen Python code and this seems to really improve readability. It would be especially great for a beginner's language, since it's important to stress proper indentation at the beginning.

  • Named and out-of-order parameters. Your example very clearly demonstrated the advantage of named operators for complex function parameters. This is a feature I don't think I've seen in any language but VHDL. (Though some Perl modules sort of cheat to get this functionality.)

  • Constrained generic types. I think this nicely solves the problem in C++ of getting confusing compile errors when you try to sort objects you've forgotten to define operator< for. This is especially important if plug in the types at runtime instead of compile-time, which it sounds like you intend to do.

Here's some things I don't like:

  • Expression reduction. This seems like it would be hard to implement and very confusing. Specifically, think about expressions like that within larger expressions. If I define "A*B", "A+B", "A/B", "A*B+C" and "(A+B)/C", what happens when I use "(A*B+C)/D"? What gets called? You could do "(A*B)" then "(A+B)/C" or "A*B+C" then "A/B" or just use the binary operators. There would be a bunch of different cases and its unclear what code would actually be executed. I think it creates too much confusion unless you can demonstrate that this would be a huge speed boost.

  • Variant records.

    The first example you showed of these was basically using them as a replacement for unions. I hate unions. I like the way you can in Java set a security manager that controls what various bits of code can and can not do. But this depends on those bits of code only accessing other objects through the public interfaces. So unions in this case would be very bad for security, and they are very bad already for type safety. I really think we're past the point where we need to save a few bytes.

    Second, you used a variable to size an array. Basically, you created much simpler syntax for dynamic memory management. I think this masks a lot of problems. What happens when you run out of memory trying to resize the array? You never explicitly resize the array, so I don't even know where you'd go about inserting code to deal with that failure. Second, what happens when that variable changes in some non-obvious way? Ie, through a pointer to it or through the union thing you described above. The array isn't resized, and nothing good can come of that.

  • Multiple kinds of pointers.

    I can't help but see so many different types of pointers as needlessly complicated and confusing. What will you really be needing pointers for? You've defined "in", "out", and "inout" parameters, so pointers are no longer needed to pass by reference. They are needed for dynamically allocated memory. And they are needed for really low-level stuff that needs to address specific bits of memory.

    I suggest instead doing this: having the simple pointer type you've defined which does not allow pointer arithmetic or pointers to arbitrary addresses. Having the address type you defined available if the security manager allows it (again, the idea of not only type safety but security from not allowing access to arbitrary regions of memory). autoptr really isn't that different from ptr...especially since in C++ it can be implemented without any language support at all. Leave the others out.

  • Function-based dynamic dispatch (polymorphism). You talk about how C++ has the fragile base class problem, that new virtual functions can't easily be added to the base class. But I think you are misinterpreting where the problem lies. The problem is not that you have to add the virtual functions to the base class. That's just the way it has to be; otherwise, very weird stuff would happen when you try myBaseClass->onlyDefinedInInheritedClass() (remember, you don't know if a shape object is a rectangle or a triangle or whatever, that's the point of polymorphism). The real problem is the way C++ represents virtual function tables in compiled code. Java, for example, does not have this problem.

Really, quite a few of these features I don't like. It seems like they just add complication to the language spec without solving any huge problem. This will both make it harder for you to create a compiler and harder for people to learn/use the language.

Re:Modula3 (1)

BinxBolling (121740) | more than 13 years ago | (#260419)

Something that a friend and I recently agreed would be nice is the ability for a function to return more than one argument.

Python's tuples let you do exactly this. Lisp has something along these lines, too, though it's a bit more cumbersome.

And in C/C++, it's not always completely unreasonable to define a struct type just for returning from a function.

Re:Design by committee (1)

Alea (122080) | more than 13 years ago | (#260420)

Ada was not designed by a committee. It was one of several proprosed languages. And it's really not a bad language (I just wrote a compiler for a subset of the language), especially considering when it was made. I'd certainly rather write Ada than Perl.

Straight jacket vs. control (4)

pi_rules (123171) | more than 13 years ago | (#260421)

I like C ... because I can manipulate the memory byte by byte in an uncontrolled manner.

I like C++ because it makes me really say what I want to do if I try and do crazy shit to memory.

I like Java because no matter what I do I can't do anything dangerous. Err wait, I hate that about it :).

C++ has a nice way of protecting people.. you need to explicitly say "Yeah I'm totally sure I need to take this hunk of memory, cast it into a void* and do some arithemtic on it." It's too long though.. the lines of source that is.

Allow a Java like straight jacket... using something like #pragma preprocessor defs or something.

#babysit_me_i_am_dumb ... this would act like Java :)
#make_sure_i_am_sure ... this would act like C++
#back_the_fuck_up ... like C -- you do what you want.


Re:Interesting (5)

Gorobei (127755) | more than 13 years ago | (#260424)

Sigh, I really don't want to add to the language flames, but here goes anyway:

Those that do not use LISP are condemned to reinvent it. Badly.

Every good computer programmer I know has designed several "mini-languages." They all improve expressability in some minor way (because they scatch an itch or are optimized for a specific domain.) But, 99% of them never catch on because they are not extensible in a "deep" fashion, or if extensible, the meta-language of extensibility is painful for real-world problems.

Languages become nasty because programmers try to write "nice" APIs for their users. E.g. the systems guys provide "clean" APIs for the library writers. The library guys provide "clean" APIs for the application writers. The application writers provide "clean" APIs for the users. Each layer uses a lot of crufty stuff in an attempt to make life easy for the users of the layer. Eventually, the entire system is cruft, and hard for everyone.

C was clean, but began to collapse when programmers were forced into heavy macro hacks to implement more complex systems.

C++ started nicely, but soon was burdened by the ancient linker. Templates have become the new evil that replaces the old evil of macros.

Fortran avoided the whole issue by making abstraction beyond the subroutine level impossible.

Common Lisp, ML, Prolog, Scheme, Smalltalk, etc, all try to be "honest" languages: the writer of a piece of code trusts his users, and the users can inspect the system they are using. Everyone is assumed to be intelligent, and "information hiding" is looked upon with a degree of suspicion. The more "features" a language has, the more it worries me: these are decisions made by the designer that I cannot change. This is why I like LISP: your program must conform to certain basic rules (it is a list,) but all other design decisions are visible to me, and probably changable by me.

Of thelist of 38 unqiue characteristics of LX, Common Lisp already has 33 of them. Indentation sensitive syntax is similar to paren-balancing syntax. The other 4 are either artifacts of non-sexpr languages, or trivially implementable in a few lines of LISP.

LISP was the original user-built, customizable language.

Re:wish list (2)

istartedi (132515) | more than 13 years ago | (#260428)

If you're going to have recursion, just make sure there is some way to trap stack faults and/or prevent hard drive thrashing... "ERROR--program foo caused a THRASH EXCEPTION in module bar. Please choose one of the following: [abort] [thrash for 30 more seconds] [keep thrashing until the process is killed or terminantes on its own]"

Need XML expertise? crism consulting []

It needs to enforce modularity! (4)

MongooseCN (139203) | more than 13 years ago | (#260431)

For example in C++ you have objects which are suppose to be seperate and thought of only through interfaces. Well it just never really works like that. You have public members which other modules can read and write, you got the "friend" keyword hack which lets other special objects access members of a certain object. All these things break all the rules of OO programming and modular programming in general.

If object A is dependant on a certain public member always being available from object B and suddenly the variable is assigned different types of values or used in another way, the object A will have to be changed to accept the changes in B. Well this synchonization never usually happens unless there is a lot of documentation written (We all know coders love to write documenation!) or it finally produces a bug and you whip out the debugger and start tracing...

This is just one of the many examples. I would like to see a language where objects are forced to be seperate and truly defined only by their interfaces. C++ almost had it until it introduced all the hack keywords which broke everything.

A truly modular lanuage would be great for a Open Source language because people could work on different objects without having to worry about the internal details being compatible with another coder's object. This would allow parrallel coding to work more efficiently. Also when people join on Open Source projects, they don't have to time to go through all the code in the project to see how things work, they only have the time to look at a few sections, understand those and start coding. With enforced modular code, the new coder will only have to look at interfaces to understand how a program works.

Modularity is the key to making Open Source work.

Re:Ohw, I dunno (1)

Nohea (142708) | more than 13 years ago | (#260433)

Uh oh, here we go again.

Just after we did Guido.

Re:What nobody else wants (or will say)... (5)

mliggett (144093) | more than 13 years ago | (#260436)

High-level languages don't always result in slow code. Probably the strongest counterexample is Objective Caml [] . Functional (1st class functions; lexical closures), OO, exceptions, strictly typed, type inferencing, parameterized modules (and classes), a macro system that lets you extend and modify syntax (in camlp4) and more. The language is probably 10x as expressive as C (e.g. it takes, on average, 1/10 the space to say the same thing in OCaml as C), but it compiles to near-C speeds and sizes (sometimes beats it). This is a 15-year old project with a liberal license (LGPL) that works on UNIX, Windows and Mac OS! An older version (Caml Light) works on Palm OS. More people should be considering languages like this for complicated problems where performance is an issue!

The answer is... (1)

Fat Lenny (150637) | more than 13 years ago | (#260437)

Parrot! []


What is your goal with the language? (5)

chipuni (156625) | more than 13 years ago | (#260441)

It's easy enough to design a language. But your real question should be...

What is so insanely great about this language that would convince a programmer to use it?

From my brief reading of the webpage, the language seems to be a mish-mash between Pascal, Perl, C, and Python. Those are all good languages... but I didn't see any reason why Pascal, Perl, C, or Python users should switch to your language.

Remember that getting in a language is hard. Right now, many programming tools already support the major languages. Unless you have a large corporation behind your language, it's hard to get enough mindshare to get all the tools that programmers want. Are you really willing to do the compiler, debugger, profiler, editor, and all yourself? Across all platforms?

Before you create a new language, I recommend that you do two things:

  1. Find out why Perl, a language that has mostly accumulated its present form, rather than was designed, has become so popular.
  2. Find out why Eiffel, an incredibly well- designed language that has multi- platform support, excellent tools, and a company behind it, has only remained a niche language.

What we need is C++... (1)

imagineer_bob (163708) | more than 13 years ago | (#260443)

...with garbage collection.

Lisp gives you nothing. (2)

Ars-Fartsica (166957) | more than 13 years ago | (#260445)

Lisp is nice from the naive point of view, but try implementing a large piece of real code in it. You find out very quickly that LISP is really nothing more than a syntax - there is nothing there to build on - you get to rebuild every library you might have ever wanted all over again.

This is but one reason Lisp is just an academic curiosity these days.

Functional Language (1)

rusti999 (167057) | more than 13 years ago | (#260446)

It's interesting that in the Slashdot community there's hardly any discussion on functional languages, e.g. Lisp, ML, or Haskell. I'm taking a Programming Languages course this semester, and in it I'm exposed to Standard ML. This is my first exposure to a functional language, and I'm hooked! The feature that interests me most is type inference and polymorphism. Not the polymorphism that you see in mainstream object-oriented languages like Java or C++. It is elegant, and the way an functional program is written, developers will be less prone to write bugs. Around 20 years ago John Backus in his Turing Award lecture proposes an functional programming system as the alternative to languages based on Von Neumann architecture. It is amazing that after 20 years, this idea hasn't really caught up in the mainstream (ACM Digital Library subscribers can download the lecture online). Of course there are arguments of performance and so on. But this is what innovation and research are for. I believe there are a lot of interesting things going on in programming language research, and if the open-source effort wants to make a significant impact, they should look into it. As a closing note, I want to restate what my professor said in class a few days ago. He said that the ideas used in Java have been around for about 20 years, but only now they are brought into mainstream usage. C, C++, Java, and now C#, they are basically the same language with slight variations and improvements. Are the open-source community brave enough to venture out to explore completely new territory?

Re:What nobody else wants (or will say)... (5)

tshak (173364) | more than 13 years ago | (#260448)

You are forgetting the core purpose of a computer - it's supposed to do the work for US, not US the work for it. This is a concept I think many of us "tech geeks" and engineers forget. Although I don't agree with the "just throw hardware at it" attitude, abstraction exists so that we can create more "quicker and easier". You make some good points - especially applicable when it comes to small real-time OS's - but even JAVA is running great on cell phones.

No offense at all, but unless you're coding an OS, you need to let go of your outdated concepts of low "level code running super efficient" and recognize that abstraction and OOP are here to help the HUMANS - the HUMANS are not created to help the machine! Just imagine Linux being ALL ASM! Unmanageable.

Re:Define a problem domain for your language (2)

Reality Master 101 (179095) | more than 13 years ago | (#260453)

The retarded horse with a gimpy leg.

You're joking, right? C is the old, mean, sunuvabitch granddad horse that might not be as flashy as these younguns running around, but can still kick their ass when it's time to get some work done.

C is still the high-level language that produces the fastest code.*

*Except for FORTRAN, which still kicks C's ass on numerical applications because of the "pointer problem", and yes C++ can produce code as fast as C, but it's much more difficult due to the complexity of the language. Of course, compilers still don't produce code as good as hand-coded assembly language and please don't quote me the "myth of the magic compiler" that is supposed to produce code better than humans because you can always code whatever tricks humans would do into the compiler, blah, blah. That's total crap. Compilers produce crappy assembly language. The problem is that no one cares anymore. I've never seen a proof, but I suspect the perfect optimizing compiler is a travelling salesman-class problem. Does anyone have any proofs of my suspicions? Oh well, enough of this digression. :)


Re:Great languages come about to solve real proble (2)

Reality Master 101 (179095) | more than 13 years ago | (#260454)

When developers (Pike + friends) needed an efficient, processor-independent language for systems programming, they created C.

Just for the record, C was created by Dennis Ritchie and Ken Thompson. Primarily Ritchie, I believe.


Likes/dislikes (4)

AuMatar (183847) | more than 13 years ago | (#260460)

Since no one seems to be hitting the question much, Ill be the first.

Digit grouping- makes programs far more readable
Base selection- Will make low level programming easier by making the bases explicit. No more problems due to forgetting an h or b.

In/out specifying in param lists- will increase efficiency and help tell when functions will actually change a parameter.

Tabbing as program structure- Its going to cause problems. People will think that lines will be executed conditionally when they won't be due to forgetting a tab (and vice versa). The reason for a grouping char was to force them to think about what is/isn't in a statement

Underscore ignoring- Too confusing. People will try to read each others code and be unable to figure out what open_file is. Either make _ illegal or let it be a full character.

Too many keywords- will make language hard to learn. Plus too much typing.

Preconditions- If one compiler uses it for optimization and another throws an error at a broken one, your code will do two VERY different things on the compilers. Choose one, then it may be cool.

Named/out of order arguments- will cause confusion and bugs

Lack of types- will cause inefficencies of too much/little space being allocated. Also having compiler defined types like integer wioll make programs too compiler dependent.

Customizable for/cases/etc- It will cause confusion when programmers start taking standard language ideas and twist them. Trust me on this.

No opinion
Case insensitive- doesn't make a huge difference, but I do see it causing confusion as the _ ignoring will.

Im curious- what is the use of this language? I see a basic language, a lot of sytactic sugar with no real use, and a lot of features that will make compiler writing EXTREMELY difficult. Not to mention that most of the language features will be rarely used- You really are trying to add too much to one language. This language does everything, but wont be able to do all of it well. Jack of all trades, master of none.

And you have one major question left to answer- So why should I use it? What feature(s) does it have that the existing languages don't? I don't see any- in fact you define its features in terms of other languages that have them. You need something that is yours and yours alone if you want this to suceed.

Supporting the act of programming (1)

3seas (184403) | more than 13 years ago | (#260461)

As I understand it, there are some 30,000 programming languages. More created in a short history of computer programming than documented human written languages in all of recorded human history.

Do we really need that list of programming languages to grow? Or do we need to step back and take a broader, more objective view of what the purpose of programming is?

The act of programming is to take complexity and define it down into simpler terms, eventually to where the product is usable by the end user. So you could say that the act of programming is to create the automation of complexity that is to be controlled in simpler terms.

At the very base level of what hardware is being programmed, you have the bit. First level Abstraction of "on" and "off", machine language. As programming language abstraction evolved in the development of newer languages, all that has really happened is that of building of a tower of higher and higher level abstractions. A real tower of babel.

But ultimately we know that machine language is where the best optimization can happen. Higher levels of abstraction are really only for our convience, untill that tower starts swaying to much in the clouds and we forget how we got there.

While it is clear that the focus is on making a better programming language (for any given field of use) and that this has lead to the clouds, perhaps what needs to happen is figure out what is really needed in order to better automate the use of the languages we already have.

In other words, instead of creating another higher level language, figure out how to apply
something like Machine Language better.

I've had this problem understanding how a profession and even a hobbie for some, applies the
practice of automating complexity but can't very well figure out how to automate the process of automating complexity.

I suggest that the concept of "language" inherently cannot solve the problem, but rather only compound it, naturally.

The place to begin is in identifying the set of actions we apply in using languages, regardless of which language, human or machine.

We start/stop begin/end steps

We keep track of what step we are at

we get input

we select where we get input from

We select where we send output

we do things one step at a time

we look up the meaning of things, then do the steps

we identify things, then do steps based on this

we put constraints on what we look up and what we identify in order to narrow/focus the search and identies and steps to follow.

Doesn't matter what language you are using, you are going to do these things in processing that language.

Rather than another language, how about an action set that allows development to become able to automate more and more, the use of the languages we already have?

3 S.E.A.S - Virtual Interaction Configuration (VIC) - VISION OF VISIONS!

who wants this hyp-o-rama to continue anyway? (1)

zoftie (195518) | more than 13 years ago | (#260463)

Next major language. Gimme a break, most major
languages has been forced upon to us, like
COBOL, revolutionary, English like language.

Then there we byte compiled languages. No major
feat, just adding layers to isoltate things.
Really people have been adding layers everywhere.
So java took it over board, woo hoo...

I don't need a new language that I will have
to learn, because corporate mongers think I should. Improve on present ones.

There is no glory in impoving the old though...
just lots of effort reuse.

Re:Supporting the act of programming (1)

quinto2000 (211211) | more than 13 years ago | (#260466)

Do we really need that list of programming languages to grow?

Yes. The beauty of programming languages is that there is one for every purpose. As the uses for a computer increase in number and change in nature, it is natural that new languages get invented to better fit those uses. Of course, old languages die hard, but the language most used is the relevant one.
With that said, the curse of all programming is the so-called general purpose language, that tries to be all things and ends up nothing.

In the rest of your post, what you say seems true - but doesn't imply that we have too many programming languages. Rather, think of the long list of languages as a search for the many best solutions, each version getting a bit better. Having many languages to choose from is a blessing, not a curse.

Modula3 (1)

Z4rd0Z (211373) | more than 13 years ago | (#260468)

I didn't read the specifications for this language in great detail, but I did speed read it, and its syntax looks similar to Modula3.

Something that a friend and I recently agreed would be nice is the ability for a function to return more than one argument.

Re:Another victory for buzzwordism! (1)

King of the World (212739) | more than 13 years ago | (#260470)

Actually Perl and Python are excellent examples of languages designed the open source way. Rather than specing a language and waiting three years for a compiler to turn up (a la C/C++) they debate the feature and develop the feature into the compiler at the same time. I prefer this piecemeal way of doing it. Although one could argue that major architectural decisions can't be made by little steps it's the same problem for any software (open source or not). You must get developers to agree on a direction either way

Re:Why the grail fight yet again? (2)

Spinality (214521) | more than 13 years ago | (#260473)

Bravo. This is the right set of questions to ask anybody embarking on a language design project. I couldn't resist making an earlier comment about the things I wish had been present in the last few broad-applicability languages I was using, but you're right, even though there is plenty wrong with today's languages the solution is (probably) not Yet Another Language Standard.

Aside: Here's my favorite example of an ideal match between a language construct and a semantic behavior: typing a command line with a bunch of pipes and forks. "ls | grep | foo | more" was such a leap forward from manually naming and manipulating temporary files. It lets us control a complex suite of functions through a very simple interface model. Interface specifications are our great contribution to the advancement of knowledge. They let us take a complex system, and simplify its behavior and definition by organizing it in terms of independent components. And yet interface definition, management, publication, and revision is one of the things we've done worst through the years.

JMHO - Trevor

Nice feature list, a few comments (5)

Spinality (214521) | more than 13 years ago | (#260474)

Here are a few random comments, based on a history of having designed many languages through the years (none of which you've ever heard about). I hope this isn't considered too bloated a comment; sorry if it pisses you off, but I find the topic so interesting.

Comments. Make it really easy to provide strong in-line documentation. Don't, for example, emulate whatever brain-dead folks at M$ are responsible for VB still not permitting comments after the "_" used for line continuations, making it impossible to have function parameters documented one-per-line. Consider multiple documentation-related conventions, e.g. "//" for end-of-line comments, perhaps support for standardized structured comment blocks in preambles, ways to comment-out and uncomment blocks of code, ways to group sets of procedures, ways to draw separator lines etc. within listings (printed listings are still useful even in this day and age), ways to generate indices/crossrefs etc. Think of it as an algorithm publication problem.

PL/1 disease. You've proposed lots of good features. However, as others have pointed out, it will be easy to overload the language with a bazillion keywords and features to satsify every participant's biases. At the end, there will be n separate incarnations of the language, consisting of each user's set of preferred constructs. Nobody will really grasp the whole thing. Instead, strive for the kind of expressive purity of C (better: LISP), where a small number of primitive syntactic components can yield a rich semantics. It's a hard problem, and frankly a collaborative effort rarely can yield the conceptual purity that a single author can impart. But don't give up.

Extensibility. The most useful languages (IMO) can be extended to suit new situations. In many complex environments, it's better to adapt the language of the solution to match the language of the problem. This is why meaningful names, operator overloading, shared libraries, named constants, preprocessor definitions etc. are so helpful -- you can extend a language's working suite of concepts by documenting the specific interfaces used to interact with a particular execution environment or problem domain. So, for example, resist including I/O primitives and instead make it easy to create extensions from within the language. (Why consider them extensions rather than just traditional function calls? So that we can specify compile-time properties and behavior for their interfaces, such as argument marshalling, synchronization, error handling, exception conditions, etc., without bloating the runtime environment.)

Encapsulation. We should always be able to replace a named entity that appears to be an atomic value (integer, string, etc.) with a named property having a complex programmatic implementation, with either compile-time or run-time behavior. Such a replacement should be transparent to clients of the associated interface or name. Preferably, this should be possible within a narrow lexical scope, not just between packages or interfaces.

Integrated data definition/metadata. Try to bridge the gulf between the language's internal namespace and the external database environment. It should be anathema to reference entities using names stored or specified as character strings ("MyDatabase.OpenTable('Employees').Fields('SSN')" as we must do in so many languages when referencing external data). Instead, somehow let us bind the external data definitions into the compiler's namespace, so that referring to "Employees.FirstNaame" generates a compile-time error. (Obviously, we need to control the binding semantics so that in some cases this occurs at run-time, in some cases at link/load time, in some cases at compile-time, in some cases at preprocessing time.) Ideally, the same mechanism should support run-time interfaces to external resources such as CORBA components, including run-time retrieval of interface metadata.

Incremental compilation. Design the interactive programming environment, the language, and the compiler together, a la Smalltalk, rather than using the raw source code paradigm. Assume that we'll want the ability to dereference variables, determine variable scope, jump to definitions, view cross-references, etc., all while editing the source. This isn't really a language design issue, other than putting an emphasis on components that support separate compilation. But if you build your first compiler this way, e.g. via a p-code implementation, all your successor environments will preserve the interactive development model rather than the batch compilation model.

Explicit declaration and lexical scope. Help us find those dangling/incorrect references.

Constants and other compile-time tools. Give us strong support for creating highly-readable code that nevertheless can compile efficiently into in-line code and integer arithmetic. Combining the ability to drill-down to the physical machine with high-level encapsulation and incremental compilation would give us a wonderful span of control. (This is what we love about Smalltalk, being able to hack the running device drivers from inside the source code editor.)

Asynchrony, continuation-passing, message-passing, interrupts, critical sections, real-time constraints, shared memory, etc. Give serious thought to how deep issues of OS programming would be handled. If possible, address such issues through highly-visible fundamental mechanisms rather than hacks. For example, if you want to provide a way for two execution threads to share write access to a variable, implement some kind of encapsulation that provides well-defined interfaces and behaviors, rather than permitting indeterminate and possibly system-crashing results by making it look like a normal variable.

Well, that's enough blather for the moment. I hope these comments are useful. A few inspirations I'd love for you to consider in language design: C and BLIS, for their conceptual simplicity; Cedar, for its richness and language/environment integration; Smalltalk, for its extensibility and structural encouragement of small code fragments rather than monolithic procedures; CLU (and Simula and Smalltalk and SQL-embedded languages) for integration of external and internal data.

Good luck. -- Trevor

Re:It needs to enforce modularity! (2)

mcdirmid (222110) | more than 13 years ago | (#260477)

You should check out Jiazzi, a project I'm working on, which provides a component/module construct for Java, enforcing access for classes inside as opposed to outside of components, and has an explicit notion of import and multiple instantiation of the same component in different contexts (think seperately-compiled templates):

Re:Another victory for buzzwordism! (1)

KarmaBlackballed (222917) | more than 13 years ago | (#260478)

All languages are open source to their users in the sense that everyone can see everything that makes them up (the grammer). Heck, even English is open source, ain't it!

~~ the real world is much simpler ~~

Modern trends in language design. (2)

bertok (226922) | more than 13 years ago | (#260479)

I've notices that these days the two biggest trends in high-level language design is the ability to 'round-trip' and a "seperation of concerns".

What I mean by 'round-trip' is that it should be possible to parse the language, make some complex transformation, and spit code back out without loosing a lot of information. This in general is impossible in C and C++ because macros operate at a higher level than the core language, and because a single line of source code in a header file can mean different things depending on the context in which it's included.

The second big advancement is an extension of the OO model called Aspect Oriented programming. There have been a number of studies in the area, and many of them show impressive gains in performance, or reduction in code size. The goal of AO programming is seperating loosely connected tasks that normally have to be interleaved by the programmer, and automating the process, which is called weaving. This is normally done by allowing "after-the-fact" additions to code using glob style operators. For example, it's possible to add interfaces to a class without modifying it's source code, or by 'wrapping' functions or groups of functions in before-after style blocks. Take a look at AspectJ [] , which is a backwards compatible extension to Java.

Mozart, what an original name! (3)

blamario (227479) | more than 13 years ago | (#260480)

When I first saw the story, I thought of another (and IMO more innovative) programming language/system called Mozart [] . Would it really hurt to at least check Google for "Mozart programming language" before you name your new project? Not that the original is very original either... If you decide to change the project name, may I suggest not to use Beethoven?

Comments on the features so far (3)

Kletus Cassidy (230405) | more than 13 years ago | (#260482)

I'll split my post up into my ideas on the features you have now and my suggestions for features I'd like in a programming language. Good luck. :)

Current Features

The current features I didn't mention are the ones I thought were well thought out or didn't really have any issues with.
  • style insensitive names: These sounds like it will cause more confusion and cause more problems than it will solve (that said, is there actually a problem that it solves or was this just a cool feature you thought of hacking in?).

  • using keyword: Be careful about Keonig lookup [] if your language isn't going to dynamically load classes like Java does. Some people think the "using" or "import" style keywords should behave like #include but they usually are more subtle than that.
Features To Consider

  • Threading library: Multithreaded programming is more efficient than the using multiple processes and has grown increasingly popular. The fact that languages like C++ do not have a standard threading library unlike Java is a bad blow.

  • Virtual functions: Be consistent with how virtual functions are used. One of the many failings of C++ is that the behavior of virtual functions is completely unintuitive; virtual func s can't be called in a constructor or destructor, lookup for overloaded functions stops at the current class instead of all the way up the inheritance heirarchy, etc. Keep inheritance simple, C++'s private, public vs. protected inheritance is a mess.

  • Platform independent numeric types: Like byte, int32, int8, int64.

  • Code based documentation: Something similar to javadoc or perlpod. It is great to be able to get an overview of a whole project simply by reading documentation generated by the code.

  • Resumable exceptions: The idea that blocks of code in exceptions can be retried is nice but even cooler would be to borrow a leaf from the Smalltalk book and mark exceptions as resumable or not.

Tower of Babel (1) (245353) | more than 13 years ago | (#260485)

I was going to cuss this language, but it does look quite good...
But should things be open-sourced when they are on version 0.01? Why not put a bit of effort in first - get to a point where I can be impressed by some action rather than smalltalk (pun intended).

Wrong angle (4)

pkesel (246048) | more than 13 years ago | (#260486)

I think asking "What features do you want?" is short sighted. You should be asking, "What do you want to do with this language?"

If you're wanting to write server-side web apps your not going to focus on a GUI framework. If you're wanting to write a MOM, you're going to think data structures and serialization, as well as sockets. When you know what you're doing with it then you can say, "What features?"

Server side apps would be well-served by a VM with dynamic class loading. MOM would do well to have some well-constructed socket features and easy threading, plus some standard serialization support. GUI is going to need a good event managing system.

I think writing a language because you're looking for the next greatest thing since Java is wasteful, disruptive, and serving no relevant purpose.

What nobody else wants (or will say)... (5)

localroger (258128) | more than 13 years ago | (#260487)

Truth to the hardware. Really.

I have been involved in something close to a war with the very bright, inspired, but slightly misguided developers of firmware for a device I use every day for about 6 years. The firmware was written in C++. The day I saw it (back in '95) I said "This is the best product in our industry in more than a decade. If only it was faster." It implements a smart, well thought-out language for newbies to use to program this embedded peripheral in the environments where it will be most used. (Think truck drivers providing input.) Everything rocks except the fact that the smart, well thought-out synthetic development language can only execute about 200 instructions a second.

OK, this is on a 20MHz 80186, but I learned on a 4MHz 8080A. I know there's a 6-level interrupt system but this is still really bad..

Fast-forward. I have sold a *lot* of these beasties. But the competition have moved forward, and now while they still aren't as smart or well thought-out, sheer processor improvements have made one or two of them very fast. Lately I had an application that had to be very fast. I made a comment about going to the competition. This melted enought ice to cause the sea level to change. After some bantering, I suggested that I might benefit if I could download x86 machine language code as part of my pidgin programmin' language file. To my everlasting amazement the factory guys agreed and worked out a primitive API with me.

11,000 lines of code later I have an application running on this cool little box even its makers never realized was possible. Why? It's amazing what you can do when every low-level counter isn't coded in double-precision floating point and system stuff doesn't go through two layers of indirection (C++, dontcha know).

Abstraction can be very useful but it can also be a very short dead end. I told this company in 1995 that it was cheaper to write assembly language software than it was to replace an 80186 with an 80386; today they have done the 80386 thing and still don't have the speed I've achieved in their older instrument with better code. Sure, lots of code can be done at high abstraction with little or no loss -- but when you do all the code that way you lose a sense of what the machine is actually doing. I really don't like languages that obfuscate what is really going on to create some "virtual environment" where efficiencies are not apparent. It is very easily to get yourself into situations that look reasonable but where exponential resource requirements develop.

The best computer languages IMNSHO are line based, not character based. They have line counts somewhat related to object code byte counts. They have a human parsing-time somewhat relatable to processor parsing-time. Sometimes this makes them harder to use than groovier languages that exploit human perception windows, but when you do learn to use them you will be able to write code that works and doesn't bog down a server farm.

C was good at the fast thing but poor at the lines vs. characters thing. (Really, I think Dante's Devil has an extra fork sharpened up for whoever came up with the whole dumbass stream-of-characters idea.) C++ isn't good at anything except confusing people. The many other languages invented since 1985 or so are all trying very hard to be both C/C++ and the things C/C++ isn't.

Someone mentioned what a tragedy it is that the objects in C++ have been hacked. Well, what else did you expect? OO itself is a totally cocked idea, and welding OO onto something once thought of as "portable assembly language" (ralph, ralph) is kind of like mating a monkey with an iguana. I'll admit it's a long time since I was in college but I was gabberflasted to find that an engineer who graduated in 1995 was unaware that 0.1 is an infinitely repeating "decimal" in binary floating point notation, so that 1/10*10=0.9999999 unless you round it off; and furthermore that the single-precision libraries account for this but that the double-precision libraries don't, because the doubles figure you can work out for yourself when you want to round off. It's all there in Knuth but who reads him any more when there's all this cool Java* and derivative crap running around?

Oh well my rant for now. Karma down 3 from what, eh? It's late and I'm still dealing with this fscking stomach flu. Bah. If it can't be done in 1802 assembly is it really worth doing, I say.

Re:<Insert-deity>-damn indentation-sensitive (2)

Zeinfeld (263942) | more than 13 years ago | (#260489)

Just get a decent editor that can hack indentation syntax. We had that with OCCAM twenty years ago.

There are plenty of indentation mode packages arround for emacs already.

Some real problems (2)

Zeinfeld (263942) | more than 13 years ago | (#260490)

First off most language design has always been open source. Microsoft Visual Basic is a rare example of a closed development process over an extended time. Java being the only other that comes to mind (there is a 'standards body' but Sun retains a veto).

I don't see any attempt at a formal definition of the language. Before designing a programming language you should know about operational semantics, denotational semantics and all that good stuff.

There are severe problems with the syntax. The reason the flexible syntax of FORTRAN and COBOL was abandoned was that it introduced bugs. There is a space probe lost on the wrong course because of DO FOR I = 1, 10 being mistyped and interpreted as DOFORI = 1.10.

Program modularity hacks tend to be just that. Multiple inheritance was wildly popular in academia and an utter failure in commercial programming. MIT undergrads could hack it on a student project but when applied on an industrial scale the result was utter confusion. The more someone likes multiple inheritance the more difficult it is to decipher their code.

I don't think we need a new declarative programming language. What would be nice is a good revision of C. C++ was a disaster, give me C any day. Objective C was promising but lost. Java is unfortunately tied to Sun's strategic objective of dislodging Intel and Microsoft (why not have a go at Cisco while they are at it).

If Microsoft was to get the idea of doing a gcc front end for C# they might just get traction. It has all the programming advantages of Java without the four fold loss of performance caused by compiling to a virtual machine based on an obsolete SPARC chip. [yes I know the best java coders can write code that is faster than the worst C coders, the best C coders are a very different story].

What we are really lacking in the Internet age is a language with good handling of communications and parallelism - particularly loosely coupled multiprocessors. Now that Tony Hoare is at Microsoft I guess we can hope that some CSP/OCCAMish features might make it into C#

Re:Great languages come about to solve real proble (4)

Zeinfeld (263942) | more than 13 years ago | (#260492)

When developers (Pike + friends) needed an efficient, processor-independent language for systems programming, they created C

Actually they took an existing language called BCPL and wrote a subset called B, then they added a few features back to create C. BCPL was in turn a subset of CPL the all singing all dancing replacement for ALGOL 68 which was a little too good at being all singing and dancing.

In the case of C they wrote the language arround the compiler and vice versa.

Cross Lang support (2)

Giggles Of Doom (267141) | more than 13 years ago | (#260494)

Has anyone else gotten pissed that something like Visual Studio doesn't work as a studio? What would be really cool is to have the ablitiy to write in multiple languages in one program. Obviously not everything is going to work and it would be tough, but just think of being able to write that calls some math.cpp() or showme.vbasic() function...

wish list (1)

Anonymous Admin (304403) | more than 13 years ago | (#260495)

sane pointer manipulation, useful data types, simple data type conversions, integrated structs and unions the ability to easily redefine a block of memory as some other datatype. recursive functions, (yes, I know it is evil, but often useful). awww crud. just cut to the chase and give me a telepathic compiler.

Re:Interesting (3)

frob2600 (309047) | more than 13 years ago | (#260497)

LISP, what can I say? This is one of the coolest languages you will ever suddenly understand while writing code in it. I don't know everything in the language yet. But I have to agree that this language is very good.

I would advise any person who wants to develop their own language to take a good look at LISP first. You may not need a new language, but even if you do -- you will have a bunch of great ideas to start with.

"Do not meddle in the affairs of sysadmins,


frob2600 (309047) | more than 13 years ago | (#260498)

You need to have COME FROM, gotos are for wussies who need their hands held. If you are a real programmer you know where you should be looking for the next instruction. And this should be the only control construct. I prefer a language where I don't have to spend too much time thinking about which way I want to implement a loop. Having only one way to get something done is better. We don't want another mess like perl becoming popular.

Data type: we don't need no stinking data types. ['nuff said]

Comments are for simps, don't allow them. I prefer a language like BRAINF*** where anything that is not a valid command is ignored by the compiler -- but it would be even better if anything that was not a valid command crashed the compiler with obscure messages.

And whatever you do, make sure all the commands cannot be understood by any person will less than 7 doctorates. We don't want Visual Basic programmers to think about using our new language of choice. Make sure the language is also impossible to read even if you understand it. [For an example look at INTERCAL].

As a few final pointers on your way to language success. Make sure your documentation consists only of the following line:
Just do what you are supposed to do and you will be fine.
Then release the source to the compiler -- of course it must be written in the language and no others [to prove it is not a toy language. Toy languages cannot be used to write their own compilers.] And after that all you need to do is refuse to update any bugs that might show up. It will be as popular as Java within the week.

I would also recommend that you find a way to make large random prime numbers and integeral part of the binary -- but I have not worked that part out yet.

"Do not meddle in the affairs of sysadmins,

Re:How is this better (1)

Ayende Rahien (309542) | more than 13 years ago | (#260504)

Actually, it resemble more of Ada, not that there is much difference between OP & Ada.

Keep an open mind! (5)

melquiades (314628) | more than 13 years ago | (#260506)

I'm sure there are going to be a lot posts saying things like, "What's the point of this? Why are you bothering? Who needs another programming language? Everything you are doing has already been done better, and it was all useless anyway." I got a lot of that crap when Eidola was Slashdotted recently.

Keep an open mind. If you're not the sort of person who can enjoy new ideas that are cool but may turn out to be useless, just go read another thread.

There's an interesting study [] about the much-abused field of visual programming languages. The researchers polled programmers who worked with visual and non-visual languages to see which they liked best, and which was most effective. Their main result? Programmers' opinions of a language correlated strongly with how long they'd been using it. In other word, programmers have an overwhelmingly strong bias for the familiar; they are so strongly biased towards what they are used to that they can't really make objective judgements about unfamiliar ideas. Not surprising, but easy to forget!

This bias is a tremendous barrier to new technology. If everyone with an interesting but questionable idea gets shouted down, a lot of useful ideas are lost. Think of the brave souls who installed Linux before it was really usable while everyone was saying "OSes have been done before. Why are you bothering?"...and thank them now.

Then give Mozart and LX a fair hearing. There are some good ideas there; let's help them mature.

Ohw, I dunno (2) (321932) | more than 13 years ago | (#260507)

So, I'm intruiged, click on the link, and the first line I notice:

"Indentation sensitive syntax"

See if this still sounds like a good idea after you track a bug down to an editor expanding tabs into spaces or spaces into tabs.

Especially if you are interested in Open Source, where every one uses a different editor this is bound to haunt you at some point.

Language design tips (4)

Bi()hazard (323405) | more than 13 years ago | (#260508)

only? *smack* you're saying you want to remove functionality so it can look pretty? fool, if you make a language like that anyone who wants to use an exotic base (which can be useful to efficiently and clearly express a variety of problems) will use another language. Tip for those of you who want to make new languages: we don't need niche languages. We need something that does everything, and usually does it well. A standard language we can master, rather than trying to be proficient in C,C++,Java,perl, etc.

For example, in the number base problem you could use d,o,h, and b for defaults, but if you include a line like "define #c base 37" now you can use 1000c to represent 1000 base 37. Or, you could say "include numberbases.lib" and get a whole bunch of definitions and functions right away. Or, if you were insane, you could say "language assembly { ...assembly code implementing base 37...}"

Which brings me to another point: there's a lot of legacy code in other languages, so it would be very nice to be able to copy and paste it into a hybrid program. While that may encourage bad programming practice, we want people to use the language, not run away when they realize theyll have 2 years of rewriting the same old stuff before they can do anything interesting. It also gives you a quick and easy way to smack down anyone who claims your language isn't as efficient as some other one for whatever specific problem.

way too many languages... (2)

janpod66 (323734) | more than 13 years ago | (#260509)

What features would I like? I think that's pretty easy to answer by reference to existing languages. Java is pretty nice for many of the applications I have. For some applications, I would like to have the additional facilities found in Sather. I also like OCAML. And for interactive and GUI applications, I like Smalltalk.

The problem isn't lack of languages, it's lack of commitment to working on existing systems. For example, Guido preferred going off and doing his own thing with Python rather than create a free Smalltalk implementation. The result is that we now have Python, a language that's a little bit nicer to use than Smalltalk but whose implementation is a whole lot worse than that of existing Smalltallk implementations. If people keep starting from scratch, no wonder that implementations hardly ever get really good.

It's kind of ironic that LX is tied to a system called "Mozart", which is also the name of another new, experimental language and environment.

Re:Interesting (1)

oodl (398345) | more than 13 years ago | (#260512)

Not that Lisp doesn't have most of those features... but I think that people that haven't been initiated into Lisp's greatness will find these features more palatable and understandable in Dylan.

Re:Modula3 (1)

oodl (398345) | more than 13 years ago | (#260513)

> A function that returns more than one value isn't a function.

Then what would you call it? It sure is useful.

In Dylan you can do something like:
let (quotient, remainder) = 2 / 3;

Re:Some real problems (1)

oodl (398345) | more than 13 years ago | (#260514)

> MIT undergrads could hack it on a student
> project but when applied on an industrial scale
> the result was utter confusion. The more someone
> likes multiple inheritance the more difficult
> it is to decipher their code.

Multiple inheritance is great. The problem is how the object-oriented language that became the most popular (C++) implemented it, which makes it a nightmare in that language. Other programming languages don't have a problem with multiple inheritance.

Re:Interesting (2)

oodl (398345) | more than 13 years ago | (#260515)

Dylan on the other hand is a heavily-mutated descendant of Lisp which is fully object-oriented, has infix notation, and a module system. In Dylan, after writing a program with no type information, the programmer can later optimize his program for more efficient execution by supplying type information to the compiler. Nearly all entities in Dylan (including functions, classes, and basic data types such as integers) are first class objects. Additionally Dylan supports multiple inheritance, polymorphism, multiple dispatch, keyword arguments, object introspection, and many other advanced features.

Re:Modula3 (2)

oodl (398345) | more than 13 years ago | (#260516)

> Python's tuples let you do exactly this.

But in a language such as Dylan, you can directly return multiple values:

let (quotient, remainder) = 2 / 3;

And this can be efficiently implemented by the compiler.

> And in C/C++, it's not always completely
> unreasonable to define a struct type just for > returning from a function.

It's also a pain in the arse.

Re:What I'd like to see. (3)

oodl (398345) | more than 13 years ago | (#260517)

Dylan has all the features you are interested in:

Compiled and Interpreted YES
A good standard library YES
Truly Object Oriented (like Smalltalk) YES (In Dylan even methods are objects)
Support flexibility YES (Dylan has hygenic macro system)

Re:Define a problem domain for your language (3)

oodl (398345) | more than 13 years ago | (#260518)

> C is still the high-level language that produces the fastest code.*

CMU Common Lisp performs better for some number crunching. Dylan is fast also. Also I think some of the functional languages such as ML perform quite well.

And all of these languages are much higher-level and more productive than C.

Simple pointers and references (1)

arkeon (410421) | more than 13 years ago | (#260519)

Whatever it is, make the pointers and references easy to use, the guys in c++ must of been smoking crack.

Another victory for buzzwordism! (4)

Flying Headless Goku (411378) | more than 13 years ago | (#260522)

Could the next one be designed "the Open Source Way"?


There is no source code to a language design, so the concept of open source simply does not apply. Can we please try to preserve some distinct denotative meaning in our words, and not just throw them in wherever we want to exploit their connotations?

Yet another top-level post accepted for being buzzword compliant.

How is this better (1)

certsoft (442059) | more than 13 years ago | (#260523)

Than Object Pascal as implemented by Borland in Delphi?

Re:It needs to enforce modularity! (3)

melatonin (443194) | more than 13 years ago | (#260524)

If object A is dependant on a certain public member always being available from object B and suddenly the variable is assigned different types of values or used in another way, the object A will have to be changed to accept the changes in B.

One of my biggest gripes of C++ is that when you call a method, you're actually executing a function. OK, in any language this is true, but a C++ method isn't any more flexible than a function.

In Objective-C, which is a dynamic OO language (not strongly staticly typed like C++), objects respond to messages (implemented by methods). Methods have unique signatures. For example,

- (void) setSize:(NSSize)size;

This is a message that any object can respond to if it supports "settting a size." NSSize is a two-dimension size thing (x,y). If you had an object that represented a file, it might respond to

- (void) setFileSize:(unsigned long) inBytes;

But it should not respond to:

- (void) setSize:(unsigned long) size;

The compiler will give you a warning if you do, saying that the receiving object may only implement sizeSize:(NSSize). But code will execute fine, as long as you know that the types are fine. The compiler will also check this for you if you give it the types of the objects (which you pretty much always do).

Objects are designed to talk to other objects. If you stick to a set of rules (the OpenStep/GNUstep frameworks define a great set of ground rules), you can have objects communicate with other objects easily, and not have your code bug-ridden.

Better yet, in Objective-C, you can define optional behaviour.

if ([monitoringObject respondsToSelector(@selector(sizeChanged:ofObject: )))
[monitoringObject sizeChanged:foobar ofObject:sizeableObject];
;//monitoringObject doesn't need this info.

(a note to the confused; when you send a message, the runtime "selects" a method to respond to it. That's why you see "selector" up there.)

Not the greatest example of why you would want it, but the important distinction between Obj-C and C++/Java is that you are thinking about how objects communicate, as opposed to how object types work with other types.

A truly modular lanuage would be great for a Open Source language

dude.... [] . We'd love your help.

ok, we're not building a language, but of modularity is what you want, help us complete this stuff :)

Just make a multilanguage compiler (1)

madmad (447482) | more than 13 years ago | (#260525)

Just make a multilanguage compiler, that you can swich your language inline.
i.e.(bad example follows)
#setlanguage = c
char *aString="Hello Joe";
#setlanguage = perl
aString =~ s/Hello/Goodbye/;
#setlanguage = c++
cout << aString;
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>