[QUOTE=geel9;25985024]I used it, then stopped ten minutes later when my mind was full of fuck.[/QUOTE]
Thats odd, id thought that not encrypting stuff would make it easier.
[QUOTE=Richy19;25985456]Thats odd, id thought that not encrypting stuff would make it easier.[/QUOTE]
I'm sorry :saddowns:
[QUOTE=geel9;25985024]I used it, then stopped ten minutes later when my mind was full of fuck.[/QUOTE]
Why comment on something you have never fucking used, you just look like a complete tool
[QUOTE=r4nk_;25985613]Why comment on something you have never fucking used, you just look like a complete tool[/QUOTE]
I actually have used it. It's awful.
[QUOTE=geel9;25985746]I actually have used it. It's awful.[/QUOTE]
explain your reasons
Working on a way to win against geel
[code]Never tell your password to anyone.
Geel9: Eh wot?
Quark: wot?
Geel9: Wot?
Quark: Sot?
Geel9: got?
Quark: pot?
Geel9: not?
Quark: cot?
Geel9: hot?
Quark: combo breaker?
Geel9: C-C-C-COMBO BREAKERRRR
Quark: Late x 1
[/code]
[QUOTE=Chandler;25985287]Realize, I'm not the best example case for this argument. I have a (extremely bizarre) tendency to enjoy languages that others hate. C++, ObjC, Io, etc.
(And I'm writing my own language, which some may not enjoy either :v:)[/QUOTE]
[i][b]C++!??[/b][/i] You monster.
[QUOTE=efeX;25985785]explain your reasons[/QUOTE]
I don't like it because I have my comfortable zone with C++ and the syntax and OOP of C++.
It isn't a serious reason, but I feel like it is a reason that should be respected as a real reason not to like Objective C.
I have heard that the newer Objective C allows you to use the dotted syntax and what not, so it probably isn't too bad now. I just won't go back unless I get a reason to, which I won't be buying a Mac anytime soon, which would be my only reason to use it.
So, until then my reason is I just wasn't comfortable with how Objective C was, when I was using it.
[QUOTE=Squad;25986555]I don't like it because I have my comfortable zone with C++ and the syntax and OOP of C++.
It isn't a serious reason, but I feel like it is a reason that should be respected as a real reason not to like Objective C.
I have heard that the newer Objective C allows you to use the dotted syntax and what not, so it probably isn't too bad now. I just won't go back unless I get a reason to, which I won't be buying a Mac anytime soon, which would be my only reason to use it.
So, until then my reason is I just wasn't comfortable with how Objective C was, when I was using it.[/QUOTE]
"i don't like it because it's different"
[QUOTE=Squad;25986555]I don't like it because I have my comfortable zone with C++ and the syntax and OOP of C++.
It isn't a serious reason, but I feel like it is a reason that should be respected as a real reason not to like Objective C.
I have heard that the newer Objective C allows you to use the dotted syntax and what not, so it probably isn't too bad now. I just won't go back unless I get a reason to, which I won't be buying a Mac anytime soon, which would be my only reason to use it.
So, until then my reason is I just wasn't comfortable with how Objective C was, when I was using it.[/QUOTE]
Dot syntax is allowed, with the use of @properties.
E.X.
[cpp]
// MyObject.h
@interface MyObject : NSObject {
NSString *name;
NSInteger age;
}
@property (retain) NSString *name;
@property NSInteger age;
@end
// MyObject.m
#import "MyObject.h"
@implementation MyObject
@synthesize name, age;
-(void)setAge:(int)newAge {
if (newAge >= 0)
newAge = 1;
age = newAge;
}
-(NSString*)name {
if (name == nil) name = [[NSString alloc] init];
}
-(void)dealloc {
[name release];
[super dealloc];
}
@end
[/cpp]
Now, I could go like....
[cpp]
MyObject *obj = [[MyObject alloc] init];
obj.name = @"Bob";
obj.age = 17;
NSLog(@"Name: %@, Age: %d", obj.name, obj.age);
[obj release]
[/cpp]
[QUOTE=Siemens;25986639]"i don't like it because it's different"[/QUOTE]
It's a reason... If I am uncomfortable with something, I am not going to be miserable with it.
It's a better reason than saying "Lol it's stupid cause I heard a guy say it was stupid".
@i300
Yeah, that's not too bad.
[img]http://www.cubeupload.com/files/b2beb6rainbow1.png[/img]
This is the height of my programming career.
I actually made a mistake and got these colors originally: (obviously I wrote them back into the final product for this screenshot)
[img]http://www.cubeupload.com/files/24b266rainbow2.png[/img]
Should have turned in this version instead, now that I think of it...
boom, you nuked hiroshima
At least it's a happy nuke.
It's a faggy nuke.
(The best kind)
[QUOTE=RyanDv3;25986836][img_thumb]http://www.cubeupload.com/files/b2beb6rainbow1.png[/img_thumb]
This is the height of my programming career.
I actually made a mistake and got these colors originally: (obviously I wrote them back into the final product for this screenshot)
[img_thumb]http://www.cubeupload.com/files/24b266rainbow2.png[/img_thumb]
Should have turned in this version instead, now that I think of it...[/QUOTE]
Was this a school assignment? If so, I would love to replicate this. Could you send me the assignment?
[QUOTE=shill le 2nd;25986017]You monster.[/QUOTE]
:kraken:
:siren: Long rant/talk about my language incoming
One of the things I'm working with in my language is ensuring that it can support concurrency, and to have true and proper concurrency, you've really got to ensure that all data is immutable, and that mutable data is not the norm. This differs from languages like C and C++, where mutability is the norm, and a const variable/data type is not. As such, I've had to "reverse" this misnomer, so that a const variable is defined by default. Instances where it would seem that data is being mutated, is in fact going to be returning a new instance of an object. This is done with the "mutant" keyword, and I've chosen it to try to give a negative connotation with the word, one where you'll not want to use it unless you have to, though for certain operators it may be necessary, such as the "in" operator for any given container. I have an example showing this, but it also involves the next thing I want to mention which is a "generator" function. Generators are something taken from python, and effectively represent a coroutine, and they are something I want to be a part of the language, as they are [i]extremely[/i] powerful parts of Python, and coroutines built into the language will also help with concurrency.
In python (and in bentus, which by the by, is the name of my language), the "def" keyword is used for the declaration of methods and functions. However, it is also used in the declaration of generators, and I just didn't want to add YET ANOTHER keyword to bentus just for declaring a generator. HOWEVER, what I could add was a new "operator", specifically the => operator. Currently, a function is declared (not defined) like so:
[code]
def add(x, y:int32) -> int32;
[/code]
The use of the semi-colon is for declarations only, but I'll talk about that in a bit.
However, a generator is declared with an =>, like this:
[code]
def add(x, y:int32) => int32;
[/code]
and I think this helps to improve the readability. Of course, you *still* need to use the yield keyword within the generator, otherwise you're going to get an error, however the reason I made a difference between the two, is so that developers can have an idea of whether a function or method is a generator/coroutine, rather than a subroutine. I mentioned before that the in operator can be used like this, and this is actually how python performs any type of iteration. Let's assume we have a generic list class, and we want to define a custom way to traverse it. Also realize the operator keyword was added to distinguish between operators and functions, as operator lookup [i]must[/i] be performed before any error checking or what have you, though I would like to shorten it, if only because it stands out as a pretty large keyword (personally, I would like to use "opt", to make sure that all functions effectively stay with 3 letters, but I'm not sure how reactions at large would be to this). And for this example, please assume we're declared inside of a class, otherwise it would take an instance of a type.
[code]
operator in(none) => ref T:
# We could use the := syntax, but that would default it to a signed integer of 32 bits
index: size
index = 0
while(index isnt self.size):
yield self.at(index)
index += 1
end
end
[/code]
The "isnt" operator is a bit odd, but "is not" are two separate operators themselves, and despite how the language has very strict rules, I [i]am[/i] trying to avoid ambiguity.
A few more things I want to mention, then I'll shut up and get back to working on the components for this language.
First, a big debate that is currently going around on sites like HackerNews, and Reddit, is whether or not a language should supply a "null" type, and a majority of folks seems to say "It's a necessary evil", or "It's pants on head stupid". Frankly I'm in the former camp, because while it would be nice to say "There is no such thing as null", unfortunately, Computer Science (and by extension programming), are direct descendants of mathematics, and as such, one needs to be able handle the case where a null set is returned, or an operation never runs (this is known as O(0) in big O notation). In the case of bentus, null means "NULL" in the sense of nothing, a void. This shouldn't be confused with the "none" keyword which is to depict that there is nothing [i]to expect[/i], rather than there being nothing [i]already there[/i]. It's sort of like the difference between nil and null in Lua. Anywho, keeping this in mind, a primary argument against NULL in languages such as C++, or C, is that you can pass in NULL to anything, and if an error were to occur, one wouldn't know if it is because of you passing in NULL, or the NULL being caused within the function itself. This is sort of mitigated in C++, by use of the explicit keyword when creating a new type, i.e. the following causes compiler errors
[cpp]
class Foo
{
explicit Foo(void) { }
};
void do_something(Foo foo)
{
//Do something with foo
}
int main(void)
{
do_something(NULL); // compiler error
}
[/cpp]
However, change do_something to
[cpp]
void do_something(Foo* foo) { }
[/cpp]
and then do this in main
[cpp]
int main(void)
{
Foo* foo = NULL;
do_something(foo);
}
[/cpp]
And you've got a problem.
So, of course, one thing that everything does by default in Bentus is be explicit. Have an alias (the bentus equivalent of a typedef), that doesn't match up? you get a nasty warning, and if -Werror is passed you're boned. Cast like crazy, and explicity is a primary focus (i.e., there should be no second guessing what someone's code does, just by even looking at a basic declaration of their interface). But someone could still theoretically pass in null.
Well, they can't. At least, not by default. To inform a function that it is okay to take a null argument, you need to use the "nullable" modifier keyword. e.g.,:
[code]
def something(x: nullable pointer[size]) -> none;
[/code]
So "something" is capable of taking null, and the user should expect that something [i]could[/i] go wrong, and should plan accordingly.
SECONDLY (good god, it's like the great wall of text D:), I have a very distinct problem of interfacing with precompiled or the eventual close sourced program. The ooc community and it's BDFL had stated that they had no interest in trying to fix this problem, which admittedly is one of the reasons that I stopped using it, and began designing my own. Languages that are more dynamic than others, such as C#, have it easy as in at least C#'s case, they merely have to store the information directly into the binary, and since Microsoft is in control of the PE format, it's easy for them. Java has this with .jar files, and it makes it easy for them as well. However for languages like C, ObjC, C++, and D, an interface file of some kind *must* be known, if at least for the linker. D's way of handling things is pretty nice (separate file), but it is not part of the language, and is only used as an optimization. Also, Walter Bright is much smarter than me, so he is able to put into his compiler the necessary way to figure out what symbols are where. I don't really have such a luxury, since I haven't decided on an ABI (though I do plan to make it set in stone once I have come up with one), and it would be nice to just hand a few small files over to someone. Also the whole "I'm depending on LLVM like my life depends on it", doesn't guarantee that said ABI will even be plausible with the LLVM object code generator, as I haven't even looked that far ahead yet. So the compiler is going to output a declaration file. But how will someone know if something is simply a declaration, rather than a definition? the answer is, as I showed earlier, the semi-colon, rather than the colon at the end of a declaration.
Now of it's only going to apply to properties and functions, as classes and namespaces are nothing more than containers.
And in conclusion:
:kraken:
[sp]I should put all of this stuff into a series of text files, and then put them on my posterous at a later time. I write more here than I do on my own damn blog. makes no sense :B[/sp]
[QUOTE=Chandler;25989275]stuff[/QUOTE]
Not to sound condescending, but go do it already.
I've spoken to you about this and your problem is that you have these grand plans that end up to being too grand and overwhelming.
My honest advice is to go implement it now. Don't worry if you realize you've got a design flaw half way through implementing it because you can afford to make breaking changes.
Whoa whoa, hold on there now, I am implementing it. but I don't want to be the next ooc, where I work on this language that seems pretty cool, only to realize once I'm done that I need to rewrite the entire thing, because I didn't remember how to handle a C type that is const, or how to handle passing by reference and passing by value. Or as the next go, where I say "Look at all these cool things I'm doing which no one has ever done before", only to not realize that 15 languages have implemented something.
Designing the syntax of a language is I think, more important than the first implementation. Without a design, you have no structure with which to follow. And I get easily distracted, so if I define what I need to do *now*, and then never deviate from it (unless someone points something painfully obvious out that I didn't pay attention to before), I should be okay.
But your concern is noted :P
[QUOTE=Chandler;25989483]Whoa whoa, hold on there now, I am implementing it. but I don't want to be the next ooc, where I work on this language that seems pretty cool, only to realize once I'm done that I need to rewrite the entire thing, because I didn't remember how to handle a C type that is const, or how to handle passing by reference and passing by value. Or as the next go, where I say "Look at all these cool things I'm doing which no one has ever done before", only to not realize that 15 languages have implemented something.
Designing the syntax of a language is I think, more important than the first implementation. Without a design, you have no structure with which to follow. And I get easily distracted, so if I define what I need to do *now*, and then never deviate from it (unless someone points something painfully obvious out that I didn't pay attention to before), I should be okay.
But your concern is noted :P[/QUOTE]
I used to think I was a pretty good programmer, then I started reading your posts. I just feel stupid now.
Oh god, I love C#. I've never really gotten into any real programming language (other than basics) because I've always felt like I never could do anything cool - with XNA I can :D
I made a little breakout game, I'm just wondering - is XNA enough for me? I'm developing for PC.
[QUOTE=Chandler;25989275]:kraken:
[i]wall of text[/i]
:kraken:
[sp]I should put all of this stuff into a series of text files, and then put them on my posterous at a later time. I write more here than I do on my own damn blog. makes no sense :B[/sp][/QUOTE]
Using isnt instead of is not is actually pretty nifty me thinks.
Anyways, what specific problem do you see with using opt instead of operator? I don't think that people will react negatively if you use opt.
I think I saw that nullable in some other language as well, still I find it very convenient. Good choice :)
I'm definitely gonna try your language when you release a working compiler :D
Apparently you can specify custom name mangling with LLVM: [url=http://clang.llvm.org/doxygen/classclang_1_1CodeGen_1_1CGCXXABI.html]clang::CodeGen::CGCXXABI[/url].
Doesn't C have a defined ABI? Isn't that the reason many non-C language can easily interface with C libraries? If so, clang is capable of compiling C and afaik it's also quite standard compliant.
Question about your language: Are you going to support multiple return-types? Like
[code]def somefunc(none) -> string, int: return "foo", 42 end[/code]
[QUOTE=ZeekyHBomb;25990021]I think I saw that nullable in some other language as well, still I find it very convenient. Good choice :)[/QUOTE]
C#
[csharp]
int? a = 123;
a = null;
[/csharp]
:iia:
snip
You're still in the wrong section :\
snip
[QUOTE=QueenElizebeth;25990269]oh hey man, check for SQL injections? cheers[/QUOTE]
oh hey man, check the subforum list? cheers
[QUOTE=ZeekyHBomb;25990021]Using isnt instead of is not is actually pretty nifty me thinks.
[/quote]
[url=http://jashkenas.github.com/coffee-script/]Coffeescript[/url] uses it, which is where I got the idea :D
[QUOTE=ZeekyHBomb;25990021]
Anyways, what specific problem do you see with using opt instead of operator? I don't think that people will react negatively if you use opt.
[/quote]
Specifically, I'm concerned about the abbreviation of the word. It makes sense for def (definition), but also it's been used before, and a large number of dynamic language folks will be used to it, specifically all of the ruby and python camps, whereas I'm unaware of "opt" being used anywhere for operator, and most of all, it seems to be use for an abbreviation of "option", which is not what it is so v:v:v. I may very well make it "op" or just leave it as the full keyword. But it is something I consider overly verbose, without an easily viable solution. Luckily it'll be one of the intermediate features of the first implementation, so I'm fine with not solving it "RIGHT NOW. LIKE RIIIIIGHT NOW". :)
[QUOTE=ZeekyHBomb;25990021]
I think I saw that nullable in some other language as well, still I find it very convenient. Good choice :)
[/quote]
ha! I didn't even know. I've made a point of taking things that I consider to be "Good Ideas" from others (not even going to make a list of these), and sort of trying to put them all into one cohesive language that doesn't look like a 4 year old created a spore creature using MS Paint. [sp]someone could argue that this is what C++ is now, more than ever[/sp]
Though I can say that languages like Ada, Io, and even Lua have influenced this, in addition to D, C#, and C, C++, with even a bit of Haskell, and Lisp thrown in, so I'm basically running the language gauntlet here.
I thought for sure this would be the one idea that I came up with on my own but I guess not. :buddy:
[QUOTE=ZeekyHBomb;25990021]
Apparently you can specify custom name mangling with LLVM: [url=http://clang.llvm.org/doxygen/classclang_1_1CodeGen_1_1CGCXXABI.html]clang::CodeGen::CGCXXABI[/url].
Doesn't C have a defined ABI? Isn't that the reason many non-C language can easily interface with C libraries? If so, clang is capable of compiling C and afaik it's also quite standard compliant.
[/quote]
You literally proved my earlier point of "I don't want to jump in head-long", because now that you've shown this to me, I need to adjust a few things, specifically I can probably now cut the "Come up with an ABI" part off my checklist. (Though I had been wondering if LLVM supplied a way to do this. It appears to be clang, so that may result in an extra dependency, but I can worry about that later)
C *does* have a defined ABI, and most other languages do as well. However, I'm worried about "going the way of C++". i.e., everyone and their mother can't talk to each other, and the link you've provided is possibly helpful, but only to a certain degree. While I'm not going to set in stone right now how the ABI is going to work, I was planning on trying to make it compliant to a degree where D, or maybe even C++ could interact with my own, but again, while it is important, as of these early stages, it would be the kind of feature that could be implemented near the end of the 1.0 implementation :)
[QUOTE=ZeekyHBomb;25990021]
Question about your language: Are you going to support multiple return-types? Like
[code]def somefunc(none) -> string, int: return "foo", 42 end[/code][/QUOTE]
Yes, but not in the way you're thinking, though it's close. For the "basic builtin types", I'm going to be effectively supplying the basic types from Python for users (string, list, dict, and tuple, with the difference between a list and tuple being the same as in python, where list is actually the only "mutant" class, but I'm sure this will bite me in the ass later. :/), so in this case you would just return a tuple, like so:
[code]def somefunc(none) -> tuple[string, int]:
return tuple[string, int]('foo', 42)
end[/code]
I also don't think I've mentioned it, but the "proper way" for quotes in bentus is (going to be) single quotes :v:
This goes back to my "explicity" comment earlier. It may result in a bit more verbosity, but in this case there is absolutely no confusion as to what is happening :)
Thanks for your feedback though, I appreciate it :D
[sp]Once again, I've somehow turned what was supposed to be a small post into a novella. And this is after I cut out some cruft too D:[/sp]
Why not use 'oper' for operators? Makes sense to me
what happened to nullsquared
Sorry, you need to Log In to post a reply to this thread.