There are no good C-like interpreted languages, /prog/. I plan to design a new language with the following features:
* C-like in syntax
* statically typed, not dynamically typed
* strongly typed, not weakly typed
* interpreted in the main implementation, but compilers are possible
* functions are first class objects
* classes, none of that duck typing shit
* basic data structures like vectors, lists, etc. are included, unlike in C
* templates for generic programming
Name:
Anonymous2012-02-03 21:47
Feel free to comment along the way as I ramble about various ideas for the language.
Types
In C, all the basic integral types are defined as a certain minimum of bits or greater (e.g. int is defined as a signed integer at least 16 bits wide). In this new language, all the integral types will follow the C99 fixed types convention, without the _t. That is, int8, uint8, int16, uint16, etc.
Floating point types will be named float32, float64, etc.
I might choose to include things like static storage duration and other variable modifiers like in C. Everything is on the heap though, and garbage collected.
>>5 int16
Just fuck off. You know nothing about programming languages and you'll never be talented enough to implement one.
Name:
Anonymous2012-02-03 22:04
>>7
Typing is more than just integers and floats though; classes 'are' types too.
Name:
Anonymous2012-02-03 22:06
Strings
Strings are not the abomination in C that are 'pointers to int8 terminated with a zero-value int8'. Rather, they will be essentially 'vectors of int32', storing unicode codepoints. Vectors store the length separately.
Name:
Anonymous2012-02-03 22:11
Pointers
Pointers will be included in the language, and will work with the same syntax as in C (one or more asterisks after base type for declarations, prefix asterisk to dereference, prefix ampersand to reference). However, because this language is higher level, pointer usage will be more restricted. That means no pointer arithmetic, and no casting of integers to pointers.
Name:
Anonymous2012-02-03 22:15
Why static, strong and require explicit declaration?
To be as far away as Python, et al. Without static typing, type errors only get thrown when the code is reached in runtime. Without strong typing, all sorts of type bugs occur in sloppy code. Without explicit declaration, a variable name typo goes unseen.
The general aim of this language is to create a language that is loosely inspired by C in only the good areas, adding only the good things from sepples, as well as fixing some of the shittiness of C that makes it unsuitable for modern applications, such as C strings, the lack of generic programming, and the lack of simple data structures.
Name:
Anonymous2012-02-03 22:18
Also, the C standard library is shit.
Name:
Anonymous2012-02-03 22:22
You're a fucking retard.
>>16
No it's not, it's a great standard library, you're shit.
Interpreted directly or going through a bytecode VM?
Name:
Anonymous2012-02-03 22:34
>>21
I am not sure at the moment, but I think it would be possible either way, and depend on the implementation. Which would you prefer for the canonical implementation, and why?
Wow, OP. What a great spec. You got some really big words in there like "syntax" and "statically".
Nothing about dynamic or lexical scope, closures, continuations, co-routines, dynamic dispatch, higher-order functions, modules, functors or monads, but you're off to a great start.
I mean "pointers", that's just WOW.
Name:
Anonymous2012-02-03 22:37
>>22
I would prefer bytecode interpreted, but mostly because I'm in the middle of writing a bytecode VM.
Also, a nice feature would be type inference. Then people might actually see some form of advantage over the more mature, more widely used, faster, yet more verbose C. Who cares if it brings it closer to Python, this is one of the reasons Haskell is so powerful; it is statically typed by inference makes it so much easier.
Your sarcastic and foolish response depends on the false implication that my posts constitute a 'spec'. These are just merely ideas that I'm throwing around. Now fuck off.
Embedded-C with respect to a microcontroller's architecture is sort of like having a unique language. I've worked with PICs and the language you write has to have knowledge of the arch.
>>25
Ideas for a shitty language that will--by the grace of god-- never exist?
Name:
Anonymous2012-02-03 22:48
A wise man once said ``If a programming language doesn't make you think about programming in a completely different way, you shouldn't learn it''.
If you don't make this language worthwhile, op, it will die extremely fast. Emulating C, even with improvements, is not enough to attract users (even if that's not exactly what you're intending to do).
>>29
That's a good point. However, while Lisp does make me think about programming very differently, I don't think everyone should need to learn it.
Name:
Anonymous2012-02-03 23:01
>>31
No one mentioned Lisp. Plenty of languages have this effect, from Smalltalk to Haskell, which is why they are notable.
The reason why C is notable is because of it's no bullshit approach to memory handling; malloc and free (And their accompanying helper functions) do everything you need and fuck GC. You're taking C and making it high-level; will it still have the complete control? No, no matter how you handle variables, there will still be some functions and wrapper structures between the language and the machine, so the control, at least to the extent it was before, is gone. Taking the advantages of low level and leaving them out leaves only room for advantages of high level, which had better be worth it.
Name:
Anonymous2012-02-03 23:01
check them
Name:
Anonymous2012-02-03 23:10
>>32
So you're basically saying that if I take C, and retarget/adapt it to be more suitable for application development, then all the things that made C great have been washed away?
Why? Because it's slower, has GC (presumably) and has no GUI toolkits (yet)? Although I do suppose the lack of a compile cycle will be a definate benifit.
I don't mean it can't be good or better than any alternative, but I am failing to see enough benifit to use it.
Wow me.
Name:
Anonymous2012-02-03 23:19
>>35
Development time. C doesn't have generic programming (emulating it through void pointers or the preprocessor is disgustingly bad), data structures (who wants to keep implementing vectors, lists and trees over and over again?) or decent string manipulation.
Features of this "C-like" language that are actually like C:
* C-like in syntax
* statically typed, not dynamically typed
* strongly typed, not weakly typed
* interpreted in the main implementation, but compilers are possible
* functions are first class objects
* classes, none of that duck typing shit
* basic data structures like vectors, lists, etc. are included, unlike in C
* templates for generic programming
>>35
I don't see what your argument is. You obviously failed to understand that "C-like" is a weak connection in syntax only, just like PHP is "C-like".