Perfect Language

So, I was looking at this thread http://dis.4chan.org/read/prog/1183997706/1-40 and all the various language bashing threads and was wondering... What, in the opinions of anonymous and 4chan in general, would make a perfect programming language? I am interested in both syntax and features and general flames, since they entertain me.

I would like to be able to think of an idea and have the computer detect my thoughts and compile it into machine code.

>>2
That would require people to know what they want, which more often that not, they don't. Otherwise, yeah, I agree!

ThoughtNotFoundException at line 20

http://factorcode.org/

BASIC.

Must be:
* Support dynamic (duck) typing
* Higher order functions
* Garbage collected
* Support for a JIT compiler (compile to (fast) native code)
  as well as a native FFI system (ability to call functions from external native libraries. Marshalling of args and return values should be done by VM core)
* Have a powerful macro system (defmacro)
* Support for unicode is a must
* Classes and inheritence
* Nested procedures would be cool

Haven't decided about syntax. I am quite partial to java/c/c++/js type syntax though.

>>5
Looks a lot like Forth, which I like, btw. Not really my "perfect" language, but definitely interesting.

Personally, my perfect language would be something along a little like OCaml, or maybe a more consistent, cleaner C++ with OCaml-like "type" and pattern matching, or perhaps a more consistent Python with optional typing (or a statically typed Python with type inference maybe?).

>>6
10 PRINT LOL
20 GOTO 10

>>7
Cheers for taking this thread seriously. You've inspired me, I'll write about this later.

>>7
see >>5

Perfect language ignores all typos!

So, I was looking at this thread [any thread in /prog/... also, threaded languages suck] and all the various language bashing threads and was wondering... What, in the opinions of anonymous and 4chan in general, would make a perfect programming language? I am interested in both syntax and features and general flames, since they entertain me.

>>7
Thanks for the serious response.

>> Support dynamic (duck) typing
I'm undecided as to whether I like this or not. One one hand it makes coding quicker and easier, generally speaking, which is one reason I like Python. On the other hand, (in the case of Python anyway, I'm sure you could get around it, in which case duck typing all the way!) it appears to make code completion in editors difficult, which slows coding down (in work I make heavy use of eclipse's code completion).

* Higher order functions
Agreed.

* Garbage collected
Agreed.

* Support for a JIT compiler (compile to (fast) native code)
  as well as a native FFI system (ability to call functions from external native libraries. Marshalling of args and return values should be done by VM core)
Assuming a VM based language rather than a native compiled language, I agree with this completely. Ultimately, I want a language that offers 3 options:
 - VM interpreting bytecode
 - VM JIT compiling bytecode
 - bytecode can be (optionally) native compiled during install

Option 3 allows high perfomance native compiled execution but also allows checking and verification of bytecode at install time to ensure it does what it's supposed to (maybe have a manifest where programs specify what resources they use and at install time this is verified, but this is not needed when the VM executes it as it can be checked at runtime).

I want an OS which only allows the admin to install software but users can run anything they like in a VM.

* Have a powerful macro system (defmacro)
Definitely agree with this.

* Support for unicode is a must
I'd take this one step further and say unicode by default.

* Classes and inheritence
Agreed.

* Nested procedures would be cool
Don't particularly mind, but wouldn't complain if it existed. They are useful sometimes.

>>14
What are your thoughts on language syntax?

>>15
I'm not too sure really. I've been thinking about it on and off for a good while now, but...

Some points though:
 * I like brevity.
 * I like minimalism - that is, I do not like languages bloated with keywords and constructs. The language should have enough keywords make the language features cleanly accessible, but everything else should be left to be implemented in libraries.
 * I don't much like symbols like braces all over the place, so I would prefer them to be kept to as few as needed, though no fewer.

I'll post more as I think of it. What are your thoughts on syntax?

* Support dynamic (duck) typing
Factor is a general purpose, dynamically typed, stack-based programming language.

* Higher order functions
http://factorcode.org/responder/help/show-help?topic=quotations

* Garbage collected
* Support for a JIT compiler (compile to (fast) native code)
  as well as a native FFI system (ability to call functions from external native libraries. Marshalling of args and return values should be done by VM core)
Factor has an optimizing native compiler, automatic memory management with a generational garbage collector, a powerful collections library, and various advanced language features such as higher-order programming, continuations, and extensible syntax.
...
An easy to use C library interface allows one to call C libraries without writing any glue code in C. Bindings for OpenGL, FreeType, X11, Cocoa, and Windows APIs are provided.

* Have a powerful macro system (defmacro)
http://useless-factor.blogspot.com/2007/06/macrology-never-gets-old.html

* Classes and inheritence
http://factorcode.org/responder/help/show-help?topic=classes

* Nested procedures would be cool
quotations > nested procedures
http://factorcode.org/responder/help/show-help?topic=quotations

* Support for unicode is a must
http://useless-factor.blogspot.com/2007/02/doing-unicode-right-part-1.html
http://useless-factor.blogspot.com/2007/02/doing-unicode-right-part-2.html

>>17
Factor is definitely an interesting language and I will look into it more when I get home from work. The only thing though is the syntax. It looks a lot like Forth, which I like and dislike at the same time. Like I said in a previous post, I do quite like Forth (and therefore, presumably, Factor, seeing as my first impression of Factor is a modern and improved Forth), but I find it an awkward way to actually program.

Mainly, I find a list of 'words' (by words I mean Forth words) is not as clear as a line of code in mainstream languages. Then again, there is much, much worse syntax in use in other languages, so thats a non-issue really.

perl6 will fit >>7's criteria (including syntax) i think

>>19
Don't like perl personally, I think the syntax is ugly. Though, featurewise, you could be right.

What's so essential about garbage collection?  And do you specifically mean no manual memory management or just that automatic collection is available?

>>21
I'm not who you're replying to, but:

What's so essential about garbage collection?

You can't be serious.

And do you specifically mean no manual memory management or just that automatic collection is available?

It's bad manners to hide such details, but mention me just one place where manual memory management would've given you a performance boost that you wouldn't have got in half a year via faster hardware.

>>22
No, I am serious.  Or rather I'm ignorant.  I can understand the convenience of garbage collection, but as the saying goes "It is a logical impossibility to make a language more powerful by omitting features, no matter how bad they may be".  Manual memory management obviously allows for the option for garbage collection.

I actually know the answer to my own question too, well sort of.  The answer is along the lines: "there are things that are only reasonable to do if you have garbage collection (either automatic or custom written)."  What I'm asking is simply what those features are.  And why do these features make manual collection unreasonable for the entire language?

I honestly just don't know, but I know there is a good answer.

My ultimate language:
* Has a metacircular evaluator (like Lisp)
* First-class functions and closures (most functional languages)
* Has an incremental/optional type system (like Perl6)
* Powerful type-inference system (ML or Haskell)
* As a result of the above, if you fully annotate your program, high performance (Ocaml or better).
* Mostly functional, but supports side-effects (Lisp, ML)
* Has a modern "batteries included" library (Python)
* A single canonical distribution (Perl, Tcl, Python, Ruby, etc)
* Has a central code repository (Perl's CPAN)
* Has a terse syntax (Smalltalk, Ruby, Haskell, ML)
* Has live objects (Smalltalk)
* Easy concurrency (Erlang)
* REPL (most functional languages)
* Easy to embed (Lua or Tcl)

tl;dr: I want a Lisp with a sane syntax, modern standard library, optional type system, and first-class support for concurrency

>>22
Regarding faster hardware, that is completely the wrong attitude, IMHO. Just because hardware gets faster does not mean programmers should not care about performance of their software (especially in regards to time and space _complexity_ rather than cpu _time_).

>>23
It's not what garbage collection allows you to do (it allows you to not worry about memory allocation and deallocation), but rather that manual memory management becomes difficult as software grows to the point that garbage collection yields better performance and fewer risks (if you manually manage memory, if you fuck up, you got a memory leak). Also garbage collection aids ease of development because manual garbage collection takes effort.
Manual garbage collection can, obviously, yield better performance, because you can micromanage when allocation and deallocation happens and whatnot (ie, you have more control), HOWEVER, these days garbage collectors are advanced enough that this is difficult to achieve nowadays (just like hand optimized assembly code is rarely more efficient than compiler optimized code these days).

>>23
Most garbage collected systems allow a way (an easy or a hard one) to turn of garbage collection. I don't really consider that a feature. If you need it, there's something wrong with your language implementation.

The only time I've ever needed such a feature was when I wrote a performance-critical routine in Ruby (yeah, that it every bit as ridiculous as it sounds). I read everything about Ruby's garbage collection, and tuned my inner loop to match with its inner workings; force-feeding it with efficiently packed data. As a result, everything was still slow as fuck (and I wasn't even on Rails!). Then I realized Ruby offered a convenient way to stop garbage colllection, and used it. To say ``the code ran fucking fast'' would be an understatement. I can't believe what a fucking pile of crap the Ruby garbage collector is.

tl;dr: Most language implementations provide it in some form. If you actually really do need to do it, change your implementation or language, FAST.

>>23
GC is useful for mainly for two reasons:
* Frees the programmer from worrying about tracking memory
* Makes a strong type system possible

The reasons given against GC is:
* Loss of control
* GC is slow or nondetermininstic

However, that is outdated, because:
* Only low-level languages need an exit for exceptional purposes, and such GC-based languages provide a way out (see the D programming language)
* Modern GCs are competitive with the best mallocs, and malloc isn't deterministic either.

>>26
Agreed, though *most* modern languages have very efficient garbage collectors making this a non-issue, like you said.

>>25
>Regarding faster hardware, that is completely the wrong attitude, IMHO. Just because hardware gets faster does not mean programmers should not care about performance of their software (especially in regards to time and space _complexity_ rather than cpu _time_).
That's SO what I didn't say. I meant that people who are still in '00s doing micro-optimizations like manual memory management are fucking idiots and should just go away. I'm a CS major and I'm very interested in complexity theory, and it will be a valid point however powerful the hardware becomes.

>>24
factor has all of that except the incremental/optional type system...

>>29
Ah, sorry, misunderstood you. Totally agree.

>>30
Are you one of the factor developers or what?

>>31
no. i just happen to like factor a lot because it's the closest thing to the perfect language i've ever seen.

>>32
Ah. Seems that way from the features you've mentioned. I think I'll have to give it a closer look in a little while.

LISP

>>27
How does it make a strong type system possible?

>>35
Because with a GC references to types (whether static or dynamic) are always valid.

Data only becomes "garbage" and is swept up by a GC when there are no longer any references to it. On the other hand, with manual memory management, you can deallocate/delete what's being pointed to even if there's more than one pointer, thus resulting in a program flaw, and potential bugs.

This is well known as a "dangling pointer".

I ought to add that for the above argument, I'm considering reference-counting to be a very primiting kind of GC (Perl uses this). Perhaps I should have called it "automatic memory management" instead.

>>1
Highly readable. Context-free grammar, expressible with BNF. I.e. not J.

>> quicksort=: (($:@(<#[) , (=#[) , $:@(>#[)) ({~ ?@#)) ^: (1<#)

>> n=: 50
>> <.@o. 10x^n * pi
314159265358979323846264338327950288419716939937510

>> p=: 23 ?. 23
>> p
4 22 16 15 18 14 7 8 0 21 3 13 20 9 11 19 6 17 2 5 1 10 12

>> # ~. {/\ (200,#p) $ p
40

>>36
You want to see my dangling pointer, baby?

Context-free grammar, expressible with BNF
I have two problems with this.
1.) Turing-completeness requires a context sensitive grammar.
2.) BNF is for expressing context sensitive grammars.