Slashdot Mirror
Open Source Programming Language Design
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?"
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
From your friendly Dylan-loving friend in 42
Indeed LX has some the elements of Dylan in it:
Now if you could add multiple return values... Ah if only we had them in C. Well C0X maybe, I can dream.
All your common base are belong to us.
Um.
Eiffel does not have excellent tools. Ebench in particular is a festering piece of crap.
No offense.
/ this is an xml processor in K. .xml
;";"'";oc)]/ xml from char
;apos;";"&#???;" );"&<>'",co]/ char from xml ex:{(&b&1=+\(b&:~e)-(c&1!R=x)|e:(b :L=x)&1!c:S=x)_ x} / element from xml
" '" }'x 2],:[#v:x 1;R,:[4:v:x 1;xc v;,/_f'v],L,S,s;S],R} indent:{s:1+y?R;e:-1-(|y)?L;:[~L=*t:s _ e _ y;,x,y;(,x,s#y),(,/_f[B,x]'ex t),,x,e#y]}[""]
/ K is really fast.
/ xml: (tag;data|xml+;(attr;value)*) dtd: element(,|?+*) attlist entity \d
L:"<";W:"\t\r\n",B:" ";S:"/";R:">";cut:{:[#y;(#x)_'(y _ss x)_ y:x,y;()]};join:{(#x)_(0#x),/x,/:y} oc:1!";&#",_ci 48+8 8 8 _vs*_ic/ octal from char, e.g. oc"a"
co:_ci,8 _sv -48+_ic 3_-1!/ char from octal, e.g. co""
xc:_ssr/[;"&<>'",,"[\200-\377]";("&a mp;";"<";">
cx:_ssr/[;("&";"<";">";"&
/ (s;v[;a]) from xml
dx:{a:(-S=*|a)_ a:(1+m:s?B)_ s:_ssr/[;W;B](n:x?R)#x;x:(-m+1)_(*i)_(*|i:&~x _lin W)#x:(1+n)_ x
(`$1_ m#s;:[L=*x;_f'ex x;cx x]),:[~#a@:&0<#:'a:cut[B]a;a;,{(`$n#x;-1_(2 +n:x?"=")_ x)}'a]} / xml from (s;v[;a])
xd:{s:$*x;L,s,:[2=#x;"";,/B,'{($*x),"='",(*|x),
DX:{dx@,/x@&~(x:(&b&1=+\(b:x=L)-x=R)_ x)[;1]_lin"?!"}
XD:join["\n"](,"<?xml version='1.0' encoding='UTF-8'?>"),indent xd@ xd d:dx x:"<g><f a='2'/><h>34</h><i b='3' c='asdf'>asdf</i></g>"
DX XD d
Other steps toward this standardization include Hungarian notation (probably one of the few features I actually like about Microsoft code)
You sick bastard! Hungarian notation is a hideous canker sore - it looks like gibberish and creates no end of problems. The arguments for it were weak when we all used plain old text editors, these days (with IDEs) there is simply no excuse.
FOAD
Looks to me like you've reinvented Pascal.
Programmers can cope with punctuation. C and LISP are the classic "languages of choice" and they have a fairly minimial set of keywords and punctuation to learn. Programmer's don't like syntactic sugar - it gets in the way of programming. I find the whole indentation-defined scoping disgusting; that's partly personal, but also because it will be a pain to keep track of indentation when generating code, and because tab settings vary so much.
A lot of the other things have already been addressed... based numbers, it's typical in other programming languages and mathematics to put the base at the end, it looks odd at the beginning, hard to find the actual number in question.
How do you plan to set precedence for your named operators?
C doesn't mandate anything with regard to parameter passing mechanics; a compiler is free to stuff e.g. 8 byte parameters into a single 64-bit register if it thinks it will help (e.g. in the case of a struct); I believe compilers do that already.
The result parameter... also from Pascal.... which is not necessarily a bad thing, but it's too much of a "magic" variable for me, but then maybe I'm just too used to the C/C++ return keyword.
Bleah, I can't go further, I've been up too long and the language looks too much like Pascal/Ada, and yes, that's a bad thing, for a language that is to be used in the real world.
Still, kudos for at least being out there and giving it a shot... I can only hope that somewhere in there is a decent small language trying to get out, and that it will....
Dave
Many of the interesting parts of Gnucash are implemented in Scheme (Guile). We have found that "real code" is a lot smaller, clearer, and more fun to write and work on in Scheme. I can't think of any language I would rather be using.
Plus, Scheme/LISP experience is a good filter for hiring programmers. People who don't have a working knowledge of them are generally not the sort of programmers you want to hire anyway, and I've never met a competent Scheme programmer who couldn't learn to hack any language and any problem you throw in front of them. Probably because Scheme exposes EVERY important concept of programming languages in a very visible way.
And let's talk about object systems. The Common LISP Object System makes the C++ and Java "OOP" systems look like the half-baked abortions that they are. Scheme has CLOS too, at least for Guile, in the form of GOOPS.
With Guile support for GNOME and libglade, plus tools like g-wrap for generating bindings to C libraries, I can't really imagine starting a new project in anything but Guile plus C. Bill Gribble
- interpreted and compiled
- imperative, OO, and functional
In addition, there's one class of ideas which I wind up needing to express fairly often, but for which I have yet to find a truly helpful programming language. For lack of a better name, I'll call it dynamic programming. DP is what you use to, e.g., solve the Fibonacci recurrence f(n)=f(n-1)+f(n-2). The naive implementation (with two recursive calls) runs in exponential time, but if you compute f(1), f(2),The above example is simplistic, but the idea shows up over and over. Unfortunately it's often a pain to translate from the simple human-readable statement (the value at this set of arguments depends on the values at these other sets of arguments) to machine readable code (compute the values in this order, remembering computed values for this long).
So what I'm thinking is that it wouldn't be too hard to write a compiler that did a decent job of doing the translation for you. Something like constructing out the dependency graph for one or a few representative sets of arguments, then searching for a good ordering (e.g., minimum bandwidth). It wouldn't do everything a human could, but it would sure help for those cases where it was tedious rather than difficult to write the code.
The sort of problems I can imagine this would be good for include sparse matrix manipulations (with a known sparsity structure); relatives of hidden Markov models (commonly used in speech recognition and text processing); file translation (I know how to translate a BMP to a PNG and a PNG to a JPEG, so I should be able to translate a BMP to a JPEG); and probably others I haven't thought of.
Just my $.02.
Just a comment on Object Orientation, Don't know how relevant it will be. How are objects going to be handled. There are a bucket load of different languages that handle objects in a plethora of different ways. The best, in my view, is Java - however it has a few niggly things that annoy me. I would like to see a hybrid of Pascal/Ada Typing and Java-style object Orientation. Your probably thinking they both work quite similarly, and you would be right. But my idea is this - In Java the object structure is sometimes not strict enough for my liking - in that an object derived from some superclass may be used in a context where superclass_type is expected. Sometimes this is great, sometimes it's not so great. However typing in Ada/Pascal is far more strict. I would like to see BOTH in my choice of language. Okay now you all get to flame me :)
"Rather than a soul in a body become a body in a soul" -- Gary Zukav, The Seat of the SOUL
I repeat, C and C++ should have identical performance for most tasks, because they should produce identical output code for those tasks. If you are seeing otherwise, get a better C++ compiler. The idea that C++ should somehow produce inferior performance is a myth perpetuated by ill-informed C++ naysayers.
This claim is not based on any one benchmark or a little personal experience, it's based on an intimate knowledge of both languages, and their respective compilers and implementation details. I also work in scientific computing, and happily use C++ in favour of C. If you want to see how effective C++ can really be, try looking at Blitz++ for example.
By all means make sensible comments about OCaml, but please don't spread ill-founded rumours.
Suggestion: All declarations should begin with the name of thing being declared. If names are shared, then the name should be followed by the things (eg, type of data, function, or arguments) which contribute to its identity.
C/C++ code is unnecessarily hard to read because the names of things being declared are so often buryied in a mass of type names, etc., often found very far from the left hand margin where the eye most easily finds things.
One way to implement this that seems to me to have some simplifying advantages is to simply make all declarations of the form: Object = Definition. Ex: Some_Variable = Integer(0) [or = Integer := 0]
You should look at his resume. I would not call that unexperienced.
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.
Goodbye.
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.
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.
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.
Funny you should mention this. It's been implemented in the GNU SuperOptimizer. :)
--
Standard C++ fixes some of the performance problems with earlier implementations. For an eye-opener, check out Blitz++, 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. 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, 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 to do things like generate entire class heirarchies automatically.
--
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. :)
--
...You need to have COME FROM, gotos are for wussies who need their hands held...
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.
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.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
But there isn't any ambiguity. The order gives far less meaning than the names. In the languages I've used that have named arguments (Python, Common Lisp, Smalltalk), this is never a problem. You don't assume any order, because you read the names, not the order. It reads more like a real language.
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.
For example, if we defined [ A equiv B ] iff [ A halts iff B halts ], and put B to be a trivially halting program (i.e. first instruction is halt), then we have a `solution' to the halting problem.
On the other extremity, one could specify that all side-effects, etc. should be the same, right down to register allocation, what goes where, etc., but then this is [ A equiv B ] iff [ A == B ].
The notation doesn't come from anywhere, but I hope it should be intuitive enough to see the point. It may be possible given some definitions for `functionally equivalent' to give an algorithm that will tell you when two arbitrary programs are functionally equivalent, but it is probably the case that for most definitions,
John
John_Chalisque
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. I really doubt we want code like that these days.
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,
Ehttp://eugeneciurana.com | http://ciurana.eu
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!
Ehttp://eugeneciurana.com | http://ciurana.eu
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!
but you're ok with having to download a compiler? or do youalso demand that it also compiles with gcc automatically?
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.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
> There are plenty of indentation mode packages arround for emacs already.
And I only need them for languages which lack any capacity to pretty-print, and thus force me to do it manually.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
Take a look at ML - there everything (including modules) is completely defined by its type and there is no way to go around them.
If I have to download a special interpreter or virtual machine to use it, then I'm not even going to look at it.
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?
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
One could argue that Unix has set computing back 30 years, as well.
*pulls on flame-retardent underwear*
(jfb)
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
(plot (lambda (x) (+ (sin x)(cos (* x x)))) -10 10 -2 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.
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...)
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?
now we need to go OSS in diesel cars
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.
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.
awww.. damnit, of course you're right about Ritchie vs. Pike. I've been programming and writing about programming languages (for a comp. sci. semester project) all night long, and the names started to swim...
Sorry!
--JRZ
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
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.
thanks
My blog
"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
It's nice that there are more moderation points floating around, but wouldn't it be nice if there was a way to keep idiots from getting them?
-russ
p.s. the parent of this note was not a troll. It was instead intended to encourage people to go ahead and devise their own language. THIS note, on the other hand, IS a troll.
Don't piss off The Angry Economist
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.
-- Did you try Tao3D? http://tao3d.sourceforge.net
The concrete question is: how could I get 20% more performance AND 20% more stability out of that same hardware? How do I avoid waiting 20 hours for the compiler to crush my 10Mloc of multiply included template code? How can I write code that someone in 2010 will be able to read? How do I teach new programmers good habits (when the first thing they need to learn today is: it is interpreted, or you need to pass "large things" using pointers...)
-- Did you try Tao3D? http://tao3d.sourceforge.net
LX offers half a dozen features that reinforce interfaces. The most significant one is probably the fact that the interface of a type behaves like the interface of a function, whereas in C++, you need the body of a type to really use it (allocate it, pass it as an argument, etc)
-- Did you try Tao3D? http://tao3d.sourceforge.net
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
There will be no bug because of that. The compiler will just not accept tabs as input. If you have tabs? meta-x untabify and you are done.
The current situation is worse. Code becomes misindented, people make mistakes and have trouble reading it. But they are still too lazy to fix it since the compiler generally gets it right...
-- Did you try Tao3D? http://tao3d.sourceforge.net
Point well taken. What I meant to say is: I have this language, it is frozen in my mind, but now it would be good if people could identify big issues before I'm done with the compiler. So let's say it's an RFC for a language, how's that?
-- Did you try Tao3D? http://tao3d.sourceforge.net
As I wrote elsewhere, tabs are not accepted. I give an example showing that your problems actually happens today in C/C++, precisely because of a separating character.
Underscore ignoring- Too confusing
At some point, I will have to listen (you're not the first one to say that.) But so far, I stick to it. I'm tired of stylistic wars between my_foo, myFoo and MyFoo... And I'm sure that if I impose 'integer32', there will be people to complain that it is not 'integer_32' or INTEGER_32.
Too many keywords. Plus too much typing.
LX has about 40 keywords (+ 4 short forms like 'var' for 'variant'). C++ has over 75. No further comment :-) Most real LX examples I wrote tend to be significantly shorter than C++ equivalents, in particular with templates.
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
Throwing an error here means aborting the application. And all compilers have to implement both options (tyically, one with -g, one with -O). Not any different than the 'assert' macro in C++.
Named/out of order arguments- will cause confusion and bugs
Why do you think so? The experience with Ada seemed to indicate otherwise...
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.
I am not sure I understand this very well (the "lack of types" part.) "int" size is unspecified in C or C++ as it is in LX (although most compilers today implement 32-bit, it used to be 16-bits). Also, LX defines types like integer_32.
Customizable for/cases/etc- It will cause confusion when programmers start taking standard language ideas and twist them.
The risk exists. Someone will write 'for ever'. So what? But the alternative is no switch on strings, which I don't like either.
You need something that is yours and yours alone if you want this to suceed.
Active libraries. Look on the Mozart web page for details.
-- Did you try Tao3D? http://tao3d.sourceforge.net
PL/1 disease: The complete LX spec I have currently is about 90 pages (without the lib). That's 1/10 the size of the C++ standard. Open Source design doesn't mean design by committee. Try to insert something in the Linux kernel that Linus doesn't like :-)
Extensibility: I believe LX, with reflection, offers more than most (except LISP-family languages)
Encapsulation: It's there. Look for 'properties.'
Metadata: What do you believe reflection is for :-)
Incremental compilation: See Mozart.
Compile-time tools: See the examples on active libraries and optimizations.
OS Issues: I gave some thought :-) See the {align}, {access_size}, {address} and other pragmas.
Thank you for the very useful comments.
-- Did you try Tao3D? http://tao3d.sourceforge.net
Style insensitivity: I tried to address that elsewhere. See other answers (I'm tired, it's 1:00 A :-)
About Koenig lookup: Look at the name of author of the paper you referenced. Look at the name of the other author of Xroma :-)
Threading: Considered, but outside the scope of the library I want to design currently. The one thing that exists is a possibility to specify that two pieces of code can execute in parallel (from the compiler point of view.) How you then thread them is your problem.
Platform-independent numeric types are there.
Code based documentation: Should be addressed by reflection. See the Mozart examples.
Resumable exceptions are there.
Thank you for your comments.
-- Did you try Tao3D? http://tao3d.sourceforge.net
To have fun.
-- Did you try Tao3D? http://tao3d.sourceforge.net
LX allows multiple output parameters to a function or procedure. If you can propose a syntax that is acceptable to turn that into multiple return parameters, I am likely to buy it.
:= f(D, E, F)" is syntactically ambiguous (consider placing it in an argument list...)
Unfortunately, something like "A, B, C
-- Did you try Tao3D? http://tao3d.sourceforge.net
[localhost:~/Development/mozart] ddd% wc `find . -name '*.[Chc]' -o -name '*.cpp' ` ./lx/lx.cpp
...]
163 576 5133
[... a few other files
34125 132276 1324591 total
Remember, that's a part-time job, one person, and all this code is less than 1 year old. Plus I have kids, you know :-) Version 0.01 is there to make it clear that you can't use it if you don't develop it (which actually is probably false of Mozart now...)
-- Did you try Tao3D? http://tao3d.sourceforge.net
I disagree. The design of Fortran, C, C++, Pascal, Eiffel and LISP were done behind closed doors.
I don't see any attempt at a formal definition of the language.
You are right. The good news is: the formal definition exists; it is about 90 pages long. The bad news is: it's boring, it's incomplete, and it's based on a pre indentation-sensitive version. You can find it there. And yes, I know it is not finished...
Before designing a programming language you should know about operational semantics, denotational semantics and all that good stuff.
Thanks for the recommendation :-)
-- Did you try Tao3D? http://tao3d.sourceforge.net
That's wrong. The requirement is simply that sizeof(char)=sizeof(short)=sizeof(int)=sizeof(long ). On some compilers (some Cray compilers I believe), sizeof(char)=sizeof(long)=1, and all are 64-bit...
-- Did you try Tao3D? http://tao3d.sourceforge.net
Uh oh. Good point. I did not thing about that issue. Overall, case and style insensitivity did not receive much positive appreciation here... I may scrap them.
-- Did you try Tao3D? http://tao3d.sourceforge.net
type Color is enum(Red, Green, Blue)
type speed is other real
type distance is other real
type time is other real
function Speed(distance D; time T) return speed written D/T
-- Did you try Tao3D? http://tao3d.sourceforge.net
Yes, but 10 years ago, sizeof(int)=2, today, sizeof(int)=4. And yes, I wrote "less than", but I suspect the HTML filter removed it.
-- Did you try Tao3D? http://tao3d.sourceforge.net
No, but you gave me the opportunity to give more information on important questions. Thanks.
1) I'm uncomfortable with end-of-line as a statement separator, and with indentation as structure control. It seems we're mixing lexical/expressive/publication issues with language syntax.
I am actually trying to make the two of them consistent all the time. Also note that end-of-line is not the only possible separator:
if a=3 then b:=5; c:=2; else d:=8; e:=f
There is even an 'end' keyword, so you could write a whole LX program on one line if you wanted :-)
At least, please be sure that long expressions can be spread over multiple lines with interleaved comments, and that short blocks can be expressed on a single line without resorting to '(a ? b : c)' or the like.
You can: := A +
A
B +
C
I agree with your other comments, including in many ways you're tilting at windmills...
-- Did you try Tao3D? http://tao3d.sourceforge.net
I see. But that's a policy. For some applications (such as real-time, OS or driver development), you need this kind of insecure access. If the language claims to be universal, it has to support them.
Now, what does LX give you? Two things: the first one is that you can still use "unions" and put conditional access clauses. This means that you can ensure that type safety, for one, is not broken. This does not prevent malicious access, which is apparently your concern. For this second thing, you have Mozart. Look the part on "policy control." You can have a Mozart plug-in as part of your build system that checks that unions (or variant records) are not used in the code. This will be compile-time security.
Java has the same concept but not the fragile base class problem, simply because of its implementation.
Then, we don't talk about the same thing. To me, Java has the fragile base class problem. Consider a class framework you don't own with a root class 'Car' defining a 'Speed'. The framework hypothesis is that all cars have four wheels. You'd like to add support for 6-wheel cars in a SixWheeler class. Obviously, the place where you'd like to add a 'NumberOfWheels' member would be the base Car class, but you can't, because you don't own the framework. Even if you could, you would still have an issue if another part of the class hierarchy (say, deriving from 'Bus') already had a 'NumberOfWheels' member with slightly different semantics.
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.
And the idea of the extension is that you can add such an operation. Of course, I am not suggesting doing that for a single class, but for a whole sub-hierarchy.
Another way to view it is as follows: the (Class,Method) is a sparse 2D array. C++ forces you to organize it class by class (at least for declarations). LX allows you to select different organizations, for instance having a place which defines method "PrintItForDebugging' for all classes in your hierarchy.
-- Did you try Tao3D? http://tao3d.sourceforge.net
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.
-- Did you try Tao3D? http://tao3d.sourceforge.net
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
-- Did you try Tao3D? http://tao3d.sourceforge.net
Mea culpa. It used to be called "Xroma", and I preferred that name. Then, the person who had coined the name left the company I work for, and wanted to keep the Xroma name. I had to recode the whole stuff (full of puns like Xromasomes, Xarbon, Xode, Xid, etc) in a hurry. I realized the mistake with Mozart/Oz after having coded 15000 lines that used the Mozart terminology. I am really sorry about that, but I'm tired of recoding...
-- Did you try Tao3D? http://tao3d.sourceforge.net
Hear hear!
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
From the webpage:
:= 16#FFFF_FFFF
:= 3#1000
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.
I've had this sig for three days.
Well, syntax is superficial, but it can't be ignored. I'd say semantics is 90%, but it's not everything.
--
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Your wish is my command.
--
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
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:
--
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Which is to say, they took Martin Richards' BCPL, 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.
I'm old enough to remember when discussions on Slashdot were well informed.
Maybe, but that's hardly revolutionary - the idea of composition of functions - f(g(h(x))) instead of t=h(x), u=g(t) etc. - precedes computers by a long way.
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.
Yes, they are a great contribution, but they are fundamentally shallow for many kinds of complex systems. This is because some problems have requirements (such as logging, synchronization, repeated metadata) which inherently cut accross more traditional decomposition units like classes and functions. This is why I believe aspect-oriented programming could well be the next big revolution in programming. (Disclaimer: I'm biased, I research this stuff at university). Any new language which doesn't take account of that risks being sidelined by those that do.
Female Prison Rape in NY
I would suggest that it would not only make it easier to appreciate the usefulness of Jiazzi, but would actually make it easier to understand it as a whole, if you considered what a detractor or confused newbie might say and then tried to respond to - or even pre-empt - those kind of comments. Here are some basic questions which you could answer (I am actually researching non-brittle component integration, so this is not just idle banter!):
Jiazzi is a component system that enables the construction of separately compiled and externally linked components in Java.
What does externally linked mean? External to what?
Jiazzi is not a Java language extension, instead it is an evolution of the complete Java environment that adds mechanisms for describing and linking components.
Er... why is it not an extension? Do you not introduce any new syntax? If it's not an extension, what is it? A preprocessor, a postprocessor, a style guide or set of patterns, or what?
Jiazzi allows the use of the OOP paradigm across component boundaries with components that import and export Java classes.
Why can't you use "the OOP paradigm across component boundaries" already? Just wrap components in objects for example. Of course then you may have crosscutting problems, but this is where AOP might come in.
The combination of these features in Jiazzi enables a revolutionary solution to the extensibility problem with an open class pattern.
What is an open class pattern? What is it about the solution that makes it revolutionary?
A unit is analogous to a shared or dynamically-linked library.
I find this analogy almost content-free. A jar file is similar to a dll, but so what?
Groups of classes known as ports are connected together during linking. Using ports reduces the quantity of explicit connections between units, which makes the component system scale and easier to use.
Isn't this merely a simple extension of package-private classes?
Female Prison Rape in NY
You need to implement a bidirectional relationship (assume you don't have an OODBMS or whatever that can automate this for you). Let's say that whenever you add a new Book to a Borrower's list of Borrowed Items, the Book object needs to be notified that it has been borrowed so that it can quickly return who currently has it (this is really for efficiency reasons only, but that may be very useful in e.g. a distributed environment).
You can't say
private void notifyIveBeenBorrowed() {...}
because that won't be callable from your Book class. But if Book is in another package, you have to make it public - but it should only be callable from Borrower. Even if it isn't in another package, you have to expose the method to all the other classes in your package. You could put the two classes in a package all by themselves, but that's a bit silly - and then what happens if you need another bidirectional relationship involving Book and some other class?
In the limit, a completely programmatic access control mechanism would probably be useful (please vote for the feature request I've filed in the sun java bug database for this!), but still, in my experience public and private seem to be suitable enough in the majority of cases.
Female Prison Rape in NY
Female Prison Rape in NY
YOu can find it at www.gerbil.org/tom/
From their main page:
TOM is an object-oriented programming language that advocates unplanned reuse of code. To this effect, TOM enables unplanned reuse through the following features:
A class is defined by its main definition and any extensions.
An extension can add methods, variables, and superclasses to a class.
The source of the original class is not relevant while it is extended: it is not needed and does not need recompilation; nor is recompilation required for any client code or subclasses. Extensions can even be loaded at run time.
Unplanned reuse removes the privilege of class modification from the class designer and hands it over as a right to the user. Every user has other uses for a class: the class does not need to suit them all if they can make it suit themselves.
What does this offer to the writer of classes? Using a class is no longer a binary choice: the user can be almost satisfied by it and adjust it to his needs. And you can severely update the classes in your library, e.g., add instance variables or replace methods, without requiring recompilation of any program using it, or requiring a non-backward-compatible version change of your shared library.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
TOM is GPL'd.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Actually there's no perfect optimizing compiler because the halting problem is reducible to it. Thus, there is no general way to get the fastest object code from source code. It is completely impossible with any computer which can be simulated on a turing machine.
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:
http://www.iro.umontreal.ca/~gambit/
Mine currently exists on 30 or so sheets of 'em.
// (if that's not good enough, get a better editor! :)
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:
- 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.
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.
This depends on what you are doing. I do a lot of physics related coding. One way to create clear and readable programs is to stay as close to the mathematical notation as possible. And in physics (and mathemathics) the case is essential:
V = Volume
v = speed
Phi = flow
phi = angle
etc.
Being caseinsensitive will ban this practice.
Of course, those who are used to case insensitivityhad never a problem with it. Those who are used to it will miss it. Maybe we know that John_Smith and JohnSmith are the same person. But we all know that Annemarie and Anne-Marie are different girls.
There is no overwhelming need to be case insensitive. It is a choise.
Most (non ICT) people I know are very case sensitive with their e-mail adress. They are treating it as being case sensitive though we all know it isn't. When this comes quite natural why don't make use off it in a programming language?
Hans
No source code to a language design? What about BNF, or doesn't that count? That definitly seems like langauge design to me. What about the actual yacc/lex code used to write the official compiler? There is no reason that you couldn't GPL your BNF grammar and your lacc/yex code.
Justin Dubs
It's good your soliciting ideas. You'll get a mess of conflicting opinions, but as long as you do what you think is best in the end (giving a coherent whole), taking suggestions can only make your language better.
I want to comment on one of the least important bits semantically, that has a big payoff: avoid those damn space-wasting, error inducing curly braces or begin-end pairs. If you do it where all if's require and end, ala modula-2, that'd be great. Or even better: do it in the python style, where the nesting is taken directly from the indention, eliminating a really pesky class of errors as well as all the wasted vertical space (or alternatively, eliminating those obnoxious curly braces that don't line up).
More importantly, study what's already out there. Don't do a language because you want to do a language, do a language because you think you have just the right combination of features taken from other languages, and/or have a novel idea that you feel the world would benefit from.
Oh, and -don't- go the perl route, for Pete's sake! What a mess, and getting worse. An ideal language is simple enough for an idiot, but still exceptionally powerful in the hands of an expert - complexity should come from algorithms, not a morass of alternative ways of doing things In The Language. Operating overloading is about as bizarre as the language should allow.
Also, if you do have a novel idea, make sure it wouldn't be better added to an existing language that already has some critical mass than to a new language. Some ideas could simply be implemented as a class library, while others could be added to a language proper by an open-minded project coordinator. I'd guess python or ML (Meta language, _not_ machine language) folks (two languages I respect quite a bit) would be very open to hearing of a novel idea, and I'm pretty sure there are others too.
The programming landscape is littered with good languages that died because of an 'unfamiliar' syntax.
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).
Nope... It's got an unfamilar syntax, as someone earlier pointed above.
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.
MODULE Hello
IMPORT Out
Out.String("Hello World");
Out.ln;
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.
The message on the other side of this sig is false.
Just pass by reference and return nothing.
The message on the other side of this sig is false.
Actually, it's pretty easy to misuse a dangerous C++ feature accidentally. Many C++ programmers still use the low-level C arrays without proper bounds checking.
And BTW, if you're looking for a language which makes sure you don't do any dumb things during your regular work, but also lets you go down to the individual bits if you want to, check out Ada. It's quite a good compromise: the dangerous language elements mainly have "Unchecked_" in their names, and they're syntactically separated from the the ordinary stuff so that you don't use them accidentally.
So far, your proposal lacks enumeration types (which are essential for meaningfull case statements) and distinct scalar types (so that you can't exchange row and column indices without a type conversion).
In addition, in contrast to Ada, I think exceptions with a parameter (of scalar type) would be a good idea. The solution used by POSIX.5 to cope with the many POSIX error conditions is certainly not optimal.
And if you're going to make this an Open Source language, make sure that your implementation of it can't use libraries unless you've got complete source code for them, like GNAT does.
That's not a programming language problem, that's a lazy programmers problem.
----
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
But some process like python's PEP could be a good idea...since every programmer should listen its usersm and the users of computer languages are the other programmers.
Ciao
----
FB
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.
Oh, _that_ argument again. I don't usually edit source code in Microsoft Word either. It's not the appropriate tool for the job.
-
-
Listen. Strange women lying in ponds distributing swords is no basis for a system of government.
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 ...)
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
very astute!
--
It's either on the beat or off the beat, it's that easy.
I moderate therefore I rule!
--
The point of this whole endeavor is exactly what?
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.
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.
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.
I like C ... because I can manipulate the memory byte by byte in an uncontrolled manner.
:).
... this would act like Java :) ... this would act like C++
... like C -- you do what you want.
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
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.
I am not enlightened.
I have used functional languages in university, but the chances of that making you see the beauty of them has been likened to seeing the beauty in shakespear when you are forced to read it in high school.
I think I'm missing something, here's what I see as different:
- Often iteration is implemented using recursion.
- Syntax is often minimalistic.
- Tend to be interpretted, so have the advantaged of being interpretted (altering source at run-time etc)
- Different philosophy regardling variables, sometimes completely untyped, sometime no variables at all.
Tell me what I don't see? Or are seeing incorrectly, or do you really 'have to be there'. Take it to email if you like.So what is the difference?
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
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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.
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.
Outdoor digital photography, mostly in New Engl
Uh oh, here we go again.
Just after we did Guido.
Objective Caml has all this.
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?
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!
--
--
fat lenny's gonna lick your brain today.
Uhhh... Squeak is Smalltalk. Maybe a bit more added since the ST80 definition, but it's nothing *new*.
/Brian
I actually have a bit more of a PostScript fetish myself, but I think that's just a personal quirk. I don't claim that functional languages are the be-all, end-all of language design, but there's a certain appealing rhythm to a language that seems to go "do this to this to this to this to this to..."
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
http://www.geocities.com/connorbd/tarpit/magenta.h tml
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 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:
Never play leapfrog with a unicorn. Or a juggernaut.
Read a book which covers use of friend, and encapsulation at the component level, instead of accepting naively that the "OO way" is the one true solution. OO does not offer the best encapsulation, only the best object-level encapsulation. It's possible to do better. C++ ain't perfect, but assuming that friend harms encapsulation just because too many people misuse it is ignorance.
...with garbage collection.
This is but one reason Lisp is just an academic curiosity these days.
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?
@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!
No sig for the moment.
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.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Kernighan and Dennis Ritchie created C (at least according to my books).
No, Kernighan just wrote the book. Ritchie created the language. I'm not absolutely sure about Thompson.
--
Sometimes it's best to just let stupid people be stupid.
Stripping out the virtual machine was an advance that set computing back about thirty years.
Come on! Do you really think Unix would have gotten off the ground if it was not only written in a high-level language, which was a performance penalty compared to the conventional wisdom of writing in assembly, but also used a virtual machine?? I'm sorry, but operating systems should not be written to use a virtual machine, especially on a PDP-11.
And no, Java has not proven that virtual machines are viable. In my experience, Java is on the average 10-100 times slower than C. Yes, you can create toy benchmarks that show comparable performance, but for real applications (an XML parser comes to mind, which is my particular headache) performance sucks. And always will. And yes, I used Sun's latest JDK.
--
Sometimes it's best to just let stupid people be stupid.
One could argue that Unix has set computing back 30 years, as well.
I like Unix, but freely admit there are quite a few warts. I'm curious ... what is the particular wart that you feel "sets computing back 30 years"? Surely not monolithic kernels!
--
Sometimes it's best to just let stupid people be stupid.
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.
--
Sometimes it's best to just let stupid people be stupid.
It isn't the named I dislike, so much as the out of order. The combination of the two will cause problems. If you had to name arguments but still put them in the same order, its extra typing, but not all bad. If you can put them in any order... Its a maintenance nightmare. The code takes many times longer to read. People know the order of arguments in fread, fprintf, etc. With out of order arguments people will read it and have to look up the names and what they do for every use. Or worse, assume a certain order because its how they always do it, and things start to get fucked up.
I still have more fans than freaks. WTF is wrong with you people?
Tabbing as program structure- Its going to cause problems [...] due to forgetting a tab (and vice versa).
As I wrote elsewhere, tabs are not accepted. I give an example showing that your problems actually happens today in C/C++, precisely because of a separating character.
Ive rarely see a problem in code due to the { keys- people tend to train themselves to use it all the time. With tabbing theres all sorts of problems. How long is a tab, do we have to do only 3 spaces? Only 4? Is a single space a tab? Not to mention the {} pairs make a visual and typing difference. IMHO far easier to read then tabbing.
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
Throwing an error here means aborting the application. And all compilers have to implement both options (tyically, one with -g, one with -O). Not any different than the 'assert' macro in C++.
My suggestion- implement both with different keywords. That way both of them (which are both actually fairly cool ideas) can be implemented in the same file. I doubt a compiler switch could do that.
Named/out of order arguments- will cause confusion and bugs
Why do you think so? The experience with Ada seemed to indicate otherwise...
See post below, or give me an email and I'll show you an example. Naming isn't bad, but out of order is. (Although admittedly I've never programmed Ada).
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.
I am not sure I understand this very well (the "lack of types" part.) "int" size is unspecified in C or C++ as it is in LX (although most compilers today implement 32-bit, it used to be 16-bits). Also, LX defines types like integer_32.
Ok, then thats fine. There do need to be some types with default sizes. For example C++ always defined short to be 2, long to be 4. So anything that needed to be a certain size could depend on them. Actually, I like integer_32 better, it specifies the size.
Customizable for/cases/etc- It will cause confusion when programmers start taking standard language ideas and twist them.
The risk exists. Someone will write 'for ever'. So what? But the alternative is no switch on strings, which I don't like either.
Anyone who write for ever will promptly be shot by his coworkers. So I won't worry. As for switch on strings- implement one in the language. It'd be a useful feature. But if you take a construct thats well understood and change it, people will inject bugs. Its a fact of life.
I still have more fans than freaks. WTF is wrong with you people?
Umm, I know that on my x86, sizeof(char)=1, sizeof(short)=2, sizeof(long)=4. Did you mean
Actually, if I were writing a language I would tie the sizes into basic types (like integer32 would do). It would remove potential problems by making sure sizes were always the right size (important for networking) and get rid of ugly sizeof(int) statements.
I still have more fans than freaks. WTF is wrong with you people?
*sigh* html. Last post was supposed to read- "Do you mean less than or equals?"
I still have more fans than freaks. WTF is wrong with you people?
Since no one seems to be hitting the question much, Ill be the first.
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.
I still have more fans than freaks. WTF is wrong with you people?
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!
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.
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.
let go of your outdated concepts of low "level code running super efficient"
Personally, I enjoy the challenge of writing optimized assembly code, but you're right.
The problem is that the most popular (by volume) processors today are using a machine language that was not designed to be compiler friendly. A properly designed processor architecture should take into account the hardware issues, but also the abstraction that will be used on top of it. Make it easier to write a compiler than can write very fast code. (for example, a register stack makes it easier to write faster c-style function calls)
Unfortunately, this means you have to target a specific language, but many languages use similar structural concepts, so you would still get benefits across the board.
Yeah, ok, I don't know squat about processor design. Just look at the x86 instruction set tho...
Something that a friend and I recently agreed would be nice is the ability for a function to return more than one argument.
You had me at "dicks fuck assholes".
They are developing a fully extensible language. It turns out that the only type of programming language that could do this is one that allows higher order functions (functions which can return other functions). That is, this language will have to be a functional programming language (this phrase means more than you might think).
Examples of functional programming languages are Hope, Standard ML, Lazy ML, Haskell and Miranda. If you've never heard of these languages then you should find out about them as soon as possible.
A totally extensible language would allow a programmer to add any new syntax they wanted in a declaritive (not interpretive) way. Forget having to get a new language to add a bit of syntactical sugar you just can't do without, you add it to this language.
At the moment the only way of extending a language is to write a new grammar, define all the semantics and then write a compiler which compiles this language into a well known language or assembly code. (The former is probably a better idea).
This is not a good solution because of the utter nontrivial nature of this task. What if you just wanted one more bit of syntax in C. You essentially have to write a new compiler to handle this C-plus-a-little language. You instantly throw out all the good work that GNU, or Borland or whatever has done in making a fast compiler and start from SCRATCH.
A fully extensible language would be a very special thing. By simply loading a library of syntactical defintions from a file you could turn this language into PERL, C, C++, JAVA or whatever.
Some of you will think I don't know what I'm talking about. I assure you I am not. This is theoretically possible.
A topic that would illuminate just a little what I just said is that of "combinator libraries" (this is a functional programming topic)
Sean
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
--Giving to trolls for the benefit of us all
I didn't mean to imply that you hadn't addressed these issues -- I agree that the LX and Mozart designs address many of my wish-list items. I was providing first-blush comments on metadesign issues that seemed important, mostly from past experience, before I made a detailed study of your design (which I thought might be helpful -- but RTFM is usually good advice, and in hindsight I was probably wrong to use 'ready, shoot, aim' as my approach).
Anyway, two further comments:
1) I'm uncomfortable with end-of-line as a statement separator, and with indentation as structure control. It seems we're mixing lexical/expressive/publication issues with language syntax. The issue of cleanly disambiguating program structure always seems to me more a problem for the development environment than for the language syntax. At least, please be sure that long expressions can be spread over multiple lines with interleaved comments, and that short blocks can be expressed on a single line without resorting to '(a ? b : c)' or the like.
2) There's always a tradeoff between flexibility and consistency. It's clear that LX lets us create new sublanguage dialects (e.g. by creating new infix operators, and other richly overloaded syntax). I'm afraid that one person's coding conventions could easily create code that is incomprehensible to another. I'm sure this flexibility is a design goal, or a byproduct of one, but a language capable of being all things to all people loses its charm of simplicity and readability.
Others have pointed out here that creating a new language is not to be undertaken lightly. I don't agree that there's no reason to do so, because all our existing tools suffer from certain expressive problems that limit our ability to create and manage large, complex systems. Correcting these limitations is a stated purpose for Mozart. However, in your designs I still see a muddling of issues: programming environment, language syntax, design methodology, metadata distribution, documentation, modularity/separate compilation, etc. It's hard to draw the lines in the right places. (I don't mean you've created muddled designs, but that the issues themselves are so deeply threaded. I'm not convinced that we've cut to the core issues yet.)
Think about what we love about the Lambda calculus and about algebraic notation. Each is a simple formalism, easily defined and used, providing limitless expressive power. I still yearn for a comparable underpinning for constructing robust computer systems -- a meta-LX, if you will. (Perhaps something like this is already part of the spec, and I'm just seeing the leaves of the tree rather than the trunk.) But before any Lispites and Schemites and Mary programmers raise their hands: my dream-language would (somehow) not lead to systems that can only be created and maintained by visionaries. It must somehow simplify the development problem in a way that pure lambda calculus or pure message-passing don't seem to do for most humans.
Anyway, I see this project as very useful and important, even though in many ways you're tilting at windmills.
-- We all have enough strength to endure the misfortunes of other people. La Rochefoucauld
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
-- We all have enough strength to endure the misfortunes of other people. La Rochefoucauld
Indentation makes code more readable. That is why nearly every programmer uses it. Making the syntax of a language indentation-sensitive only adds a check to this. The bad thing about indentation-sensitive syntaxes is that they usually drop the end-of-block token (end if, end while, }, etc.). And that really causes a loss of readability.
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 ~~
--- -- - -
Give me LIBERTY, or give me a check.
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.
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?
You never know how many times I've tracked bugs down to semicolon-terminated if statements. IMHO, bugs resulting from different tab stops are easier to find than inherent logic problems like this. Besides, most editors have the option to visually differentiate tabs from spaces. Also, the idea is to let other people see the structure of your code faster. That means no more debates with regards to indentation styles. A programmer friend of mine used to have a very different way of putting braces around code blocks, and we eventually found it so difficult to read after a while that we had to make a custom pretty-printer to visualize her code. She has since changed her evil ways. This is a huge step towards standardizing open source code. Since everyone will be forced to use the same indentation, all code would theoretically look the same from this point on. Other steps toward this standardization include Hungarian notation (probably one of the few features I actually like about Microsoft code) and enforcing modularization (like the Java rule of one file per public class). I would like to see more of this in future programming languages.
Pet peeve: Profane people propagating perfunctory pedantry.
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 ConsiderMy first thought on "open source programming lanugage development" was along the lines of: "You mean... like this?"
Suppose someone, call him "Dennis", produces their own computer programming language. For the sake of argument, let's call our example language 'C', because it programs Computers.
Dennis releases the language C to the public domain, by releasing sources (specs).
Then suppose someone, call him Richard, comes along and takes C and adds a few bits and pieces he wants in it plus some ideas some other people have had. Something he can only do because the language is, er, "open source".
Then, say, Bjarn and Steve come along and decide to add some features to C and Richard's C (who has named his after his favourate animal) to make it support object orientation. Bjarn calls his version "C++", and Steve calls his "Objective C".
Then, someone else, ooh, I dunno, Bill J, and maybe another person called Bill G, decide to take C++, and clean up the language and implement a virtual computer architecture in it. Bill J names his after his favourate brand of coffee, and Bill G names his after a musical note.
And all of them are able to do this because:
Dennis made his language "open source" by releasing the specs, so Richard and Bjarne were able to add features.
Richard made his extentions to the language "open source" so Steve was able to add features.
Bjarne made his extentions "open source", by documenting them again, so Bill G and Bill J were able to add features.
Would that be what "open source" development of a programming language would be like?
--
You are not alone. This is not normal. None of this is normal.
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).
1up.org
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.
- Sig this!
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.
Brackets contain world's first nanosig, highly magnified:[.]
There are plenty of indentation mode packages arround for emacs already.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
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#
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
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.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
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 swap.java() that calls some math.cpp() or showme.vbasic() function...
"A coward dies a thousand deaths, the brave but one."
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.
I have used many languages over the years. I dropped C/C++ for Java cold-turkey many years ago. I like the language a lot, but there is one thing that I have never seen in any programming language.
Take a look at Esperanto. Word order doesn't matter. In Esperanto, word endings determine which part of the sentence the word belongs to -- not the location in the sentence. "I walk my dog" could be written as "my dog I walk" and "dog my I walk" and they would all mean the exact same thing. No grammer to understand outside of the spelling of the words themselves.
Now, I am not saying that you should make a language that requires special endings or anything. I am simply saying it would be really neat to see a programming language that had NO SYNTAX RULES. Imagine the learning curve then.
http://www.google.com/profiles/malachid
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,
---
"Do not meddle in the affairs of sysadmins,
for they are subtle and quick to anger."
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,
---
"Do not meddle in the affairs of sysadmins,
for they are subtle and quick to anger."
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.
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
Needless to say, Graham attributes to Lisp itself a large part of the credit in being able to accomplish what he did.
Actually, it resemble more of Ada, not that there is much difference between OP & Ada.
--
Two witches watched two watches.
Which witch watched which watch?
You say you don't know how to use your editor? The tab key is on the left hand side of your keyboard, most likely. Usually you will find an option like "Tabs to spaces" or something like that in, ummm, maybe "Options."
There, now you can read the *rest* of the LX page.
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.
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.
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.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.
i'm the kind of person who likes to know how a language works, rather than just knowing how to.
one thing i like about Forth - the language for Mad Scientists - is how you can track through the source and find out how things work, all built up from about twenty hard coded definitions in the nucleus.
Mad Scientists clearly need a new language, and who would disagree that it should be one that offers the same scope for egomaniacal control freakery as Forth?
--
http://cosmo7.com/tecnofile
for computor experts(TM)
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.
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.
Whatever it is, make the pointers and references easy to use, the guys in c++ must of been smoking crack.
-Arkeon- Broadband Bastard
Could the next one be designed "the Open Source Way"?
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.
--
Than Object Pascal as implemented by Borland in Delphi?
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;
"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." This argument is entirely wrong. What changing the value in registers have something to do with variant record?