Open Source Programming Language Design 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?"
<Insert-deity>-damn indentation-sensitive stx (Score:2)
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.
Goodbye.
Re:Define a problem domain for your language (Score:2)
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 (Score:4)
What I'd like to see. (Score:5)
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.
Re:Define a problem domain for your language (Score:2)
Standard C++ fixes some of the performance problems with earlier implementations. For an eye-opener, check out Blitz++ [oonumerics.org], a numerical library written in C++. It performs on par with FORTRAN, sometimes even exceeding FORTRAN's vaunted numerical speed.
Standard C++ can also be much, much faster than C. The standard sorting algorithm is a typical example. std::sort is 250% to 1000% faster than qsort according to one benchmark [stanford.edu]. It is 20% to 50% faster than a hand-coded C quicksort for a particular data type. I have seen such results elsewhere -- this is just the first page Google turned up.
Yes, std::sort is using inlining to good advantage. That's not "cheating" as some may argue. C++ (and the standard library) provide the efficiency of inlining while maintaining genericity and separation. That's what templates do. It's an intrinsic part of the language. C++ and the standard library help you reduce programmer time (less code to write) and execution time in many important cases.
C++'s combination of static typing, polymorphism and generic programming while maintaining the ability to do "traditional" C-style structured programming is really, really nice. I have my choice of options for coding particular modules and I don't need to learn three different languages to do so. One could even argue that C++ supports a fourth model: with template metaprogramming [indiana.edu], one can write C++ code in a style that almost looks like functional programming in the sense that recursion is used exclusively and the code implements functions that do not modify any values. Granted, this form of coding is limited to compile-time values, but it can be used in lots of surprising ways [awl.com] to do things like generate entire class heirarchies automatically.
--
Re:Language design tips (Score:2)
Why in heaven's name would you want to do it that way? A much better approach is to compile those legacy codes into separate modules and provide the language with a way to import those modules with the ABI of the particular legacy system used. C++ can do this to a limited extent with extern "C" and there's no reason someone couldn't implement extern "FORTRAN" or some other such thing (I'm not sure if standard C++ allows extern to specify a calling convention in addition to a linkage, though).
If we really take this to extremes, we might want such a feature to handle interpreted languages as well. It gets a bit tricky around that spot, though. :)
--
Re:COME FROM (Score:3)
Oh, you mean exceptions. After all,
try {
foo...
} catch (SomeExceptionType baz) {
try_to_recover_from_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
foo...
baz:
if (some_condition)
COME FROM foo;
At least Intercal folks realize their language is a joke, I don't think Sun have caught on yet.
Re:Jikes (Score:5)
Re:Likes/dislikes (Score:4)
Any function/method with more than, oh, two arguments causes confusion and bugs. Most of the time there is no real natural order to the arguments -- perhaps some conventions, but that's about it. Does the file come first in fputs, or is that fprintf...? Does either of those make more sense then the other?
Argument ordering is usually arbitrary, but named arguments are never arbitrary. For large function calls (which would include object instantiation) keywords (named arguments) are very good.
Re:Define a problem domain for your language (Score:2)
And even if a human can write assembly better than a compiler, is it worth the cost? For the majority of us, the answer is clearly no.
Agreed! By the time loss of portability and maintainability plus development cost is considered, it will rarely be worth it. See: The story of Mel [watson-net.com]. I really doubt we want code like that these days.
Re:Define a problem domain for your language (Score:2)
Greetings!
In your comments you wrote:
What about: any large-scale application where performance and stability matter?
That is exactly my point. "Any" is not meaningful. "Any" sounds like snake oil to the person who is first exposed to your technology (blame the hordes of marketeers that preceded you). Finding a specific problem where you can empirically demonstrate that LX and Mozart outperform other means (in uptime, cost, stability, development time, etc.) will focus your efforts and your PR. That will bring people to use your technology, and they, in turn, can discover that the technology is excellent for other applications.
Mirror the success of others. Java started in the applet space. It's now used for developing everything from web to embedded to hard real-time applications. It took some time, but people eventually came around to realize the many uses of the technology.
Good luck,
EDefine a problem domain for your language (Score:5)
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.
Cheers!
ETemplate Meta Programming (Score:2)
I always knew that C++ offers more ways for obfuscated programming than C - I can't wait to show these snippets to my colleagues. :)
And funny to realize that I have just bought the book on Generative Programming that has been mentioned on that template meta programming page that features the Meta Lisp for C++ interpreter.
One more reason to read the book soon.
Mod this up!
Re:whatever it happens to be.. (Score:2)
Re:Define a problem domain for your language (Score:5)
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!
Re:<Insert-deity>-damn indentation-sensitive (Score:3)
And I only need them for languages which lack any capacity to pretty-print, and thus force me to do it manually.
--
Re:Mainstream influence of Functional Languages (Score:2)
In Java or C++, classes (not just inner classes) can be used to emulate the behavior of both closures and first-class procedures in order to code in a somewhat functional style. But that doesn't qualify a language as having functional features. My point was that in Smalltalk, closures and first-class procedures were already watered down, and Java all but eliminated them. Perl and Javascript both have real first-class procedures and real closures, and they are both stronger languages for that.
I agree that a hybrid language isn't ideal, but I was predicting what I think will happen, not what I'd like to see happen. I don't yet see a functional language that's truly ready to completely replace imperative languages for average programmers. So for the forseeable future, the mainstream languages will simply adopt functional features.
Mainstream influence of Functional Languages (Score:5)
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...)
Maybe abstraction is the evil (Score:2)
It seems virtually every language falls on its face when one tries to put abstraction on top of it. And not matter how abstract some language is, someone else comes along and wants it to be even more abstract. Just admit it: you goal is to be able to assert "all problems are solved" and expect it to just be.
If you think C collapsed because of heavy macro hacks to implement more complex systems, then I say that C has not collapsed, and is running just fine for those of use that don't try to push it beyond what it was designed for. Of course C can't be everything. But it is for me an excellent tool for most of the things I need to do. Of course some things could use something better, and I do look to greater languages for that. But that does not mean C collapsed into failure. That's only for someone who expected something out of it that it just isn't for.
I didn't see any comment from you about Forth. What say ye of Forth?
Re:No committee, but ... (Score:2)
Of course I overstated my case a bit... I was having fun (something in short supply here at the end of the semester). It's worth pointing out that the people the developers listen to tend to be people who have actually worked with the language and understand its gestalt... this new language may not even have a gestalt, and it certainly doesn't have people who have worked with it for hundreds of hours. I think until you get to that point, such things are pretty much a waste of time.
Oooo! Oooo! I want... (Score:5)
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 (Score:5)
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.
--JRZ
Re:What I'd like to see. (Score:2)
There you can find some links to other interpreters too.
Re:Straight jacket vs. control (Score:5)
Our resucue here is JNI. With this you can even segfault java
Re:My thoughts... (Score:2)
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 {
// Can now use MyNewMember.
// extends class Foo only for class Bar.
virtual void MyNewMember();
};
class Bar : Foo {
};
void Foo::myNewMember() {
}
Thanks for the comments. They help.
Re:Interesting (Score:2)
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
Re:Mozart, what an original name! (Score:2)
Re:Mandatory comments are a better idea (Score:2)
There's been many times when I pasted a snippet of perl from somewhere into my program and ran it...only later did I fix the indentation.
Not to mention, not everyone writes software the same way, so what I think is properly indented may not match what others think
Bases (Score:5)
integer Large
integer Twenty_Seven
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:What we need is C++... (Score:2)
--
Consider simplicity (Score:3)
I'm glad to see the influence of Eiffel in there. Eiffel is a language which achieves its generality not by adding features to the language, but by removing them. It doesn't try to cover everything you could want to do with a special case; it has a few well-chosen abstractions that cover a lot of ground.
Anyway, when your language description looks like a big bag of toys a programmer could use, then perhaps you should take a step back here and ask yourself "what am I contributing?" What is new about your language? If it's just syntactic sugar, then don't bother.
(I'm not saying LX is just syntactic sugar; I'm saying that your website hasn't convinced me that it isn't. The presentation of language features as a shopping list doesn't convey the real contribution of your new language.)
You seem to have a grasp of languages that are general because of their complexity (Ada, C++), but make sure you have experience with languages that are general because of their simplicity (Eiffel, scheme, Smalltalk).
A few other things:
--
Re:Define a problem domain for your language (Score:2)
Which is an interesting definition of high level language. It's also contentious; good LISP compilers beat good C compilers on a wide range of problems, and no matter how difficult you think it, LISP is a high level language.
Re:Great languages come about to solve real proble (Score:2)
Which is to say, they took Martin Richards' BCPL [ualberta.ca], stripped out the virtual machine, added a pre-processor, and called it a new language. Stripping out the virtual machine was an advance that set computing back about thirty years.
Re:Define a problem domain for your language (Score:2)
I admit it's still the quickest, that's why I said you WANT to shoot it but cant because the old sonofabitch can still gallop when it wants to.
Re:Define a problem domain for your language (Score:4)
Re:Define a problem domain for your language (Score:2)
To put it another way, compilers will never be better than people (in best-case scenario, where the people know what they're doing), because people can use the compiler and improve on the compiler's output.
------
Re: (Score:2)
Re: (Score:2)
Re:What I'd like to see. (Score:2)
- - - - -
Re:What is your goal with the language? (Score:2)
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.
Re:Another victory for buzzwordism! (Score:2)
Justin Dubs
New? Try old technology.. (Score:2)
Smalltalk, Lisp.
True, neither of these languages is ideal for all tasks, but they're both pretty impressive.
LISP runs as fast as C++, and has extensive support of programmed transformation of code. (Thus, you can create, as an app programmer) new syntax and even new semantics. (The OO system CLOS is an application, not built into the compiler.)
Smalltalk is interpreted, but is still very usable on a modern machine. Primitives can be compiled to C under Squeak. It also has beautiful introspection and semantics. It is the result of over 10 years of development in the 70's, and is still a sweet and clean language.
Both languages are still amazing and just as powerful as C... And interactive programming to boot.. But why aren't they used? Is it because programmers are so afraid of new things that they won't spend even an hour learning a different (and potentially better) syntax.
Both languages have a syntax that's far far simpler than C++ or even C. Its also much more elegant. Yet, that superficial difference seems to have sentenced them to death.
Syntax unless egragriously broken[1], is superficial. Semantics is everything.
[1] overcomplicated (APL: >100 operators, C++) Verbose (Java/Pascal).
Earlier comment; People are superficial. (Score:4)
Programmers do not like a syntax that is not close to the syntax of their first language (usually an algolic variant)..
It's no harder to get used to than C, or any other real language. Try using it with an indenting, syntax hilighting editor for a week. Now, did you spend more than a week when you learned the syntax of your first algolic language?
Anyone notice how all the languages that seem to be coming out are always algolic? And that they suck... They don't even have closures!
Syntax is superficial. Semantics is everything.
Re:What I'd like to see. (Score:3)
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 (Score:2)
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? (Score:5)
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:
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 (Score:2)
Re:My thoughts... (Score:2)
I did actually implement it
Well, I can't argue with that. I didn't realize there was a working compiler for this, I thought this was still in the design stage. Guess I should have looked around a bit more. I still think this could be confusing, but if the speed boost is there, maybe it's worth it.
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.
I did give reasons for hating them. To restate, I'd like to actually use the encapsulation for security (you can't mess with private stuff) instead of just type safety (it's easier not to mess with private stuff), like Java supports. This is impossible with unions, since members can overwrite each other's data. Not only does this feature not help me, it's impossible to do what I want because of this feature. It is really a matter of what you want the language to be used for.
This is an all-or-nothing thing with the addresses pointer type. If you can do pointer arithmetic and not unions (or vice versa), there's no gain for me.
The fragile base class problem is that you cannot extend the class.
Agreed. But what is causing the problem is not the way C++ conceptualizes polymorphism, that you add virtual operations to the base class. The real problem is an implementation detail. Java has the same concept but not the fragile base class problem, simply because of its implementation.
I'm not a low-level expert, but I believe it works something like this: given a base class with n virtual functions, an instance has a virttable[n]. Derived classes then have that same virttable[n+m] where m is their own virtual table. If the base class is then recompiled with virttable[n+1], code compiled with the new version expects the derived classes to have virttable[n+1+m] with the new spot being at index n...this isn't true, stuff breaks.
I really don't like the idea of an extension to class Foo. The point of the polymorphism is that you have a bunch of operations which can be performed on any Foo, but are implemented differently in subclasses. Conceptually, each subclass does the same thing, even though it has a different implementation. I can't reconcile this with your idea of extending class Foo only for class Bar. You seem to basically be creating multiple versions of Foo. I hope I can't make a pointer to a Foo_e (extended version of foo) point to a Foo, because then I'd get a "pure virtual function called" or something strange when I try to call a non-pure function.
Thanks for the comments. They help.
I'm glad to hear it.
My thoughts... (Score:4)
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.
Straight jacket vs. control (Score:4)
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.
Examples:
#babysit_me_i_am_dumb
#make_sure_i_am_sure
#back_the_fuck_up
Justin
Re:What I'd like to see. (Score:2)
Re:What I'd like to see. (Score:3)
In Smalltalk:
Transcript show: (Object new perform: #hash).
Re:Interesting (Score:5)
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:Mainstream influence of Functional Languages (Score:2)
Re:wish list (Score:2)
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 [maden.org]
Re:NO! NO! NO! DO NOT DO THIS! (Score:2)
That name's already taken. It's the name of a distributed programming language. It was also named after Linda Lovelace. Search for it or check out this link: http://www.cs.yale.edu/Linda/linda-lang.html.
It needs to enforce modularity! (Score:4)
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.
OCaml (Re:What I'd like to see.) (Score:2)
Besides: It has a wonderful object system, but is great for procedural programming too. It is an excellent functional language, but is great for imperative programming. It is strongly typed, but you can desactivate the typing features if you want too.
Last but not least, the performance of the compiled code is excellent, better than C++ and close to C.
Put it another way: it has what it takes to please irreconciliable communities such as the C++ people, the Lisp people and the Java people. And much more.
Also, it is, as this story suggests, designed "the open source way". That is, it is open source of course, and its design is the result of constant discussions of excellent technical level on the caml mailing-lists.
Heaven on earth, isn't it?
Re:OCaml (Re:What I'd like to see.) (Score:2)
Anyway, you know what people say... there are 3 sorts of lies: lies, damn lies, and benchmarks. So I don't think it's worth arguing on this issue. The bottom line is that OCaml has the advantage, especially compared to Lisp and Java, to provide performances of the order of system languages such as C and C++, with a much better abstraction (higher level semantics, garbage collection, command-line interpreter, etc...).
Re:What nobody else wants (or will say)... (Score:5)
Re:Squeak is the place to be! (Score:2)
/Brian
Re:Interesting (Score:2)
But it's all in what you're trying to do. I wouldn't write an operating system in PostScript, but that doesn't mean I don't think it's a good language for what it does (and a few other purposes besides).
/Brian
NO! NO! NO! DO NOT DO THIS! (Score:3)
About six years ago I went on alt.folklore.computers on Usenet to create a language spec by this very process, except I did it as a joke. You don't want to write a spec by Bazaar methods -- it's a sure guarantee of an unnecessarily baroque design that will be a bitch to implement from the ground up. If you're doing it seriously, you'll start unnecessary language wars as people pull out there MFTLs for design inspiration. You will get a reference manual two inches thick like Ada or C++. You will get bitched and whined at because your objects aren't as pure as Smalltalk, because your functions aren't as functional as ML, because you're more baroque than Perl.
Too tough even to change, now that I think of it -- I went back to try and rework Magenta into something coherent and I couldn't cram enough of the design back into my head to make any sense of it a year later. Implementation by committee can be a thing of beauty; that's how the Internet was built. But design by committee... let's just say I originally wanted to call Magenta Linda (as in Lovelace) because it sucked so bad.
/Brian
What is your goal with the language? (Score:5)
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:
"friend" in C++ can *enhance* modularity (Score:2)
Lisp gives you nothing. (Score:2)
This is but one reason Lisp is just an academic curiosity these days.
Re:Perl as good language design???? (Score:2)
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{ @p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2) +=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[ P.]/&&
close$_}%p;wait until$?;map{/^r/&&}%p;$_=$d[$q];sleep rand(2)if/\S/;print
Larry Wall won the obfuscated C contest twice, you know?
------
C'mon, flame me!
Re:What nobody else wants (or will say)... (Score:5)
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 (Score:2)
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 (Score:2)
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 (Score:4)
Likes
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.
Dislikes
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.
Mandatory comments are a better idea (Score:3)
Indentation should help the programmer to understand the code. It should not be an additional source of worry.
As such, indentation should represent the program structure. It should not embody it.
First, because this approach makes it possible to compute the indentation from the program structure, and this helps to flag many errors without the need for compilation.
But perhaps more importantly, because the indentation is computable, it is discardable.
And this makes the language easy to transcribe: you can easily copy and paste snippets of C or Perl code to and from weblogs and email messages and get them to compile, usually without worrying about spaces or tabs or newlines or any such transformations that may have occurred in the process.
Yes, properly indented code looks gorgeous, and this counts. But in any non-trivial program, semantical ugliness quickly dwarfs syntactical ugliness.
Mandatory comments would be a better idea.
Re:Why the grail fight yet again? (Score:2)
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 (Score:5)
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! (Score:2)
Modern trends in language design. (Score:2)
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 [aspectj.org], which is a backwards compatible extension to Java.
Mozart, what an original name! (Score:3)
Stop using tabs, then (Score:2)
Comments on the features so far (Score:3)
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 [hp.com] 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 ConsiderRe:What I'd like to see. (Score:2)
Java is ugly, sometimes, if you're doing things the language wasn't meant to do. Reflection is primarily a means to access compiled classes at runtime, and while it can be used to invoke methods dynamically, its certainly not meant to. If you want it to look pretty, make a library function. That's the only reason it looks pretty in other languages.
Comment removed (Score:3)
Wrong angle (Score:4)
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)... (Score:5)
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:"friend" in C++ can *enhance* modularity (Score:3)
You don't need "friend" for this -- "friend" is merely a bit of syntactic sugar that people who don't know how to use the Visitor Pattern [ootips.org] or double dispatch [object-arts.com] must resort to to get bidirectional relationships.
In your particular example, you'd want to use a seperate object to represent the borrower-book relationship (likely a State pattern object), have a method in the Book class which registers itself with a Borrower argument (or a BookVisitor argument, more generally), establishing the relationship thusly.
Private members are private for a reason.
Re:<Insert-deity>-damn indentation-sensitive (Score:2)
There are plenty of indentation mode packages arround for emacs already.
Some real problems (Score:2)
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:Some real problems (Score:2)
The design of Fortran, C, C++, Pascal, Eiffel and LISP were done behind closed doors
They were all developed the same way Linux was, someone put out a basic version, the community commented back and the lead developer may or may not accept the patch.
What you are talking about appears to be not 'open source' but 'design by committee'. That only works in one circumstance in my experience, when a single individual does most of the design work.
You are right. The good news is: the formal definition exists; it is about 90 pages long
Not a good sign, get it down to 5 pages and the language might have a chance of being implementable.
The bad news is: it's boring, it's incomplete, and it's based on a pre indentation-sensitive version
The indentation syntax has nothing to do with the semantics.
Re:Great languages come about to solve real proble (Score:4)
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 (Score:2)
Re:Interesting (Score:3)
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,
COME FROM (Score:5)
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.
::ERROR 324234092 -- YOU ARE NOT ENLIGHTENED YET!
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:Interesting (Score:2)
This depends on the language. Common Lisp, for example, has plenty of iteration constructs, including the (IMHO) fabulous loop macro (and Lisp programmers certainly don't shy away from using them). Others generally have fewer iteration constructs, but often they are still there. To what extent one uses iteration vs. recursion is, I'd wager, largely a function of culture and taste for various languages.
Ever tried to get ML's syntax into your head? :-) I like Lisp myself (which has a fairly simple syntax, although there is some there - you still do need to remember how special forms and macros work individually) because the syntax is minimalistic. Some languages are hairier, though.
This is just false. Lisp, for example, is typically compiled, just differently from the way to which people may be accustomed (some modern Lisp systems, e.g. Corman Lisp, don't even have interpreters). Many of these languages, however, are interactive which is a different thing. In the aforementioned Corman Lisp, for example, everything that you type into the read-eval-print loop gets compiled right away on the spot, so you don't notice it the same way you would compiling C, for example. ML, OCaml, Haskell, Clean, etc. all have compilers too, and many implementations are capable of making native executables.
Again, this depends on the individual language, and possibly what one means by variables.
A link to an interesting Lisp success story (Score:5)
Recently I came across the following story, which tells of Paul Graham's use of Lisp in his company, creating web-based store program, which was to become Yahoo stores.
Beating the Averages [paulgraham.com]
Needless to say, Graham attributes to Lisp itself a large part of the credit in being able to accomplish what he did.
Keep an open mind! (Score:5)
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 [cam.ac.uk] 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.
Language design tips (Score:4)
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.Re:What I'd like to see. (Score:3)
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 (Score:3)
> 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.
Re:Define a problem domain for your language (Score:3)
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
And this is one of the reasons why the Java VM technologies that are being developed along with HotSpot are so interesting since they perform profiling on the fly and restucture code for better preformance. Of course you need to pay for this profiling and restructuring during execution, but apparently Sun is betting that it's overall a performance win.
Another victory for buzzwordism! (Score:4)
Ugh.
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.
--
Re:It needs to enforce modularity! (Score:3)
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 doesn't need this info.
[monitoringObject sizeChanged:foobar ofObject:sizeableObject];
else
(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.... http://gnustep.org [gnustep.org]. We'd love your help.
ok, we're not building a language, but of modularity is what you want, help us complete this stuff :)