Dare I dream... Is it possible to have a conversation here on /prog/ about program languages in general? As well as, creating a programming language. Specs would be around the range of:
- Language doesn't already exist
(Go the fuck away and promote your favorite language somewhere else.)
- No Forced Garbage Collection
- Libraries which include Garbage Collection
- Easy to read (Maybe even easier than python)
- Mainly statically compiles binaries
- Has the option to run source code as scripts
- Full on support for OOP, but doesn't force OOP
- Support for various Operating Systems
- Doesn't add a bunch of B.S. to compiled binary, just code, options for leaving in comments.
Is it possible to have a conversation here on /prog/ about program languages in general?
Not with criteria like those.
You've pretty much just said, ``oh it lets you do anything and it's super awesome and easy!'' I want you to sit down and have a long think about how much of an idiot you were when you come up with this post.
Some of this doesn't even make sense. Comments in machine code?
Having built in support for a GC and also having its use being optional would be a very nice thing to have. It doesn't seem like it would be difficult to implement at all as well. It would introduce memory errors though, although the programmer could keep the possible sources of them low. The tricky situations could be left to garbage collection, and the tight loops with allocations in them could use malloc free style. It would be a happy combination.
- No Forced Garbage Collection
A language that handles that well is (Go the fuck away and promote your favorite language somewhere else.)
Oh. Never mind. - Libraries which include Garbage Collection
Oh, I see, you want a language that doesn't do it well. Fair enough.
Easy to read (Maybe even easier than python)
Wouldn't want to set the bar too high. Also: Go the fuck away and promote your favorite language somewhere else.
Name:
Anonymous2011-10-01 4:58
>Forced Garbage Collection
most language specs don't specify a memory algorithm, but may encourage one.
You didn't list "functional programming" in your list, not even "homoiconicity", not even "everything is an expression", therefore it sucks mightily. Moreover, the fact GC is optional means it's a manual memory management language which inherently sucks because it's boring to micromanage your bullshit when you're busy having real work to do.
What you want is assembly, C or at the very best D.
Name:
Anonymous2011-10-01 5:43
Full on support for OOP, but doesn't force OOP
I think it can't exist. As soon as you have full OOP support, people will create libraries with a more or less appropriate OOP interface. You end up forced to use OOP/
I'd go for minimal support for OOP instead -- that is lexical closures.
Libraries which include Garbage Collection No Forced Garbage Collection
GC-as-library my look a good idea at first, but in my experience it is likely that the core runtime will need it if the language is just slightly high level.
The best option in my view, the one I'm planning to work on, is to perform escape analysis in order to use dynamic allocation/GC only when needed.
Name:
Anonymous2011-10-01 5:46
>>1 if you want noiseless talks about programming language design, checkout groups.google.com/group/pilud
D could do most of this if you made a standard library that didn't assume GC.
Name:
Anonymous2011-10-01 6:50
I wonder whether static typing and two different list types (one that allows cycles and is GC'd, and one that doesn't and isn't) is a good idea.
Name:
Anonymous2011-10-01 13:19
>>12 implied is the idea that the GC is refcounting, right? Well, if those types make their way to the GC, it indeed looks like a good idea.
Name:
Anonymous2011-10-01 16:34
OP here.
I actually left the thread alone for a day... just to see if was even possible to have an honest discussion in /prog/. I'm glad to find out it's at least 50/50.
>>5
While, obviously not having already made a programming language, I won't say it wouldn't be at least a fair challenge... I like your approach.
>>9 I think it can't exist. As soon as you have full OOP support, people will create libraries with a more or less appropriate OOP interface. You end up forced to use OOP
That's the cool part. Just because someone creates a library to do X... doesn't mean everyone automatically has to use it, nor does it mean that library X is auto-added to the package in the next version of the language. It just means someone made library X.
The best option in my view, the one I'm planning to work on, is to perform escape analysis in order to use dynamic allocation/GC only when needed.
At the same point, I was thinking more along the lines of prior to app close free all allocated memory.
Really what he's talking about is two cons types - one that allows set-cdr! and set-car! and another that doesn't. You actually don't need static typing for this if you just have two different cons functions.