What are you working on?

[Ac!dL3ak]

I forgot that not everyone has awesome font rendering, give me a few minutes to redo that.

[editline]14th February 2016[/editline]

that, and it was admittedly too thin >.>

[editline]14th February 2016[/editline]

[QUOTE=cartman300;49741890]
Also why dashes in identifier names?

IO::Stdout.print-line("hello, world!\n");

[/QUOTE]

I like dashes for identifiers. I think they look pretty, clean, and otherwise fitting for most concepts. for that, you have a few options: println, printLine, print_line, print, or printf (with a newline). None of those look nice to me. print-line looks the nicest out of all of them, and conveys the idea (imo) better.

[editline]14th February 2016[/editline]

Also, the site should be fixed.

[Tamschi]

[QUOTE=Ac!dL3ak;49741857][url]http://carbon.medcat.me[/url]

I spent more time and effort on this than I wanted to.

[editline]14th February 2016[/editline]

note: the dns records may still be propagating, so give it a bit[/QUOTE]

[quote][B]do[/B] [...] [B]end.[/B][/quote] I'm getting Pascal flashbacks here.

Your language seems very verbose, which is generally a bad thing.
It apparently mirrors the atrocious C variable definitions that encourage errors too.
You also don't have a proper documentation, so this is almost guaranteed to fizzle out immediately.

Your code sample [URL="https://github.com/medcat/carbon/blob/8a3c83a77a7becaff5c99bdb89e5c727f19d7efe/doc/language/color.ca"]here[/URL] either has improper or non-semantic indentation or overall very high verbosity for class definitions (if a single class per file is forced). It doesn't constitute a proper specification, which seems to be completely absent. (A reference implementation doesn't count.)

I'm going to be a bit harsh here, but I'm not sure I can put it more lightly and still get the point across properly: The [I]idea[/I] behind this language is probably good, but the implementation of that idea seems seriously bad.

[polkm]

Douglas-Peucker creates the dankest simplification of polygons

[t]http://i.imgur.com/eYdkeFh.png[/t]

[Ac!dL3ak]

[QUOTE=Tamschi;49742064]I'm getting Pascal flashbacks here.

Your language seems very verbose, which is generally a bad thing.
It apparently mirrors the atrocious C variable definitions that encourage errors too.
You also don't have a proper documentation, so this is almost guaranteed to fizzle out immediately.

Your code sample [URL="https://github.com/medcat/carbon/blob/8a3c83a77a7becaff5c99bdb89e5c727f19d7efe/doc/language/color.ca"]here[/URL] either has improper or non-semantic indentation or overall very high verbosity for class definitions (if a single class per file is forced). It doesn't constitute a proper specification, which seems to be completely absent. (A reference implementation doesn't count.)

I'm going to be a bit harsh here, but I'm not sure I can put it more lightly and still get the point across properly: The [I]idea[/I] behind this language is probably good, but the implementation of that idea seems seriously bad.[/QUOTE]

That's an old code sample. The version of Carbon that I'm going for will not have classes; however, Carbon will still enforce a single file per module definition.

I wanted to build up a framework before I build a proper specification; a framework being a working implementation base, so I can test things in the language and see what works.

[quote]Your language seems very verbose, which is generally a bad thing.[/quote]

It's not designed to be verbose; in fact, one of my goals is to take a step back from the module structure that you're suggested to use in Ruby (due to lexical scoping and the like), and make it less verbose - the module you're in should already be well defined, it doesn't make sense to have to indent each layer for another module (see [url=https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/journey/path/pattern.rb]Rails[/url] for what I mean by that). In that sense, it's designed to be more Rust-like than Ruby-like. The do [...] end. is for parsing reasons; there may be guards on the parameters that I will add later on, and the best place to put them is before the body definition.

[quote]It apparently mirrors the atrocious C variable definitions that encourage errors too.[/quote]

I'm unsure what you mean by this.

[editline]14th February 2016[/editline]

Don't get me wrong - I want to do what I can to make the language great - and that includes taking criticisms for the bad aspects of it. I just need to make sure we're on the same page when we say that a certain aspect of it is bad.

[Fourier]

[QUOTE=polkm;49742088]Douglas-Peucker creates the dankest simplification of polygons

[t]http://i.imgur.com/eYdkeFh.png[/t][/QUOTE]

nice man, nice

[GGG KILLER]

[QUOTE=Ac!dL3ak;49742163]The version of Carbon that I'm going for will not have classes;[/QUOTE]

In the time of OOP you create a language that doesn't has Classes?
I honestly wouldn't use a language that doesn't has Classes unless I didn't had other options. Unless you're going to provide an alternative that works like or better than classes.

(Rate me dumb or whatever you want, but you still can't take away the fact that in a statically typed language classes or an equivalent alternative is fundamental)

[Tamschi]

[QUOTE=Ac!dL3ak;49742163][...]

Don't get me wrong - I want to do what I can to make the language great - and that includes taking criticisms for the bad aspects of it. I just need to make sure we're on the same page when we say that a certain aspect of it is bad.[/QUOTE]

Sure, I have no problem with criticism criticism. It's necessary here anyway because it's difficult to know what the language actually is if there's contradictory documentation.

The issue with the C definitions/declarations at the start of a method is that you can't limit them to subscopes e.g. inside an [I]if[/I] branch, so you effectively enforce use of globals for those contexts.
This is imprecise and often leads to errors and hard to understand code, as far as I've seen. It also prevents automatic typing.

The issue with verbosity isn't the grammar structure of your language as much as the keywords.
[I]do[/I] and [I]end.[/I] make it cluttered while you could have used single characters or even just indentation for this (the latter of which would especially make sense if you want to enforce a consistent style).

[editline]15th February 2016[/editline]

[QUOTE=GGG KILLER;49742270]In the time of OOP you create a language that doesn't has Classes?
I honestly wouldn't use a language that doesn't has Classes unless I didn't had other options. Unless you're going to provide an alternative that works like or better than classes.[/QUOTE]

There are a few alternatives (prototypes, some kind of template system that creates true classes during compilation...) but with a statically typed languages not having them is really quite bad since they very efficiently help with certain kinds of problems.

[Fourier]

This evalDraw thing is awesome :)
[IMG]http://i.imgur.com/NRrwpka.jpg[/IMG]

I was just messing with the formula.

[Johnny on Flame]

[QUOTE=Fourier;49742309]This evalDraw thing is awesome :)[/QUOTE]

It's one of these tools that are seriously underrated. It's feature-set for what it sets out to be is pretty good, from opengl to voxel drawing, there's everything, and it's way too easy to use.

[Ac!dL3ak]

[QUOTE=GGG KILLER;49742270]In the time of OOP you create a language that doesn't has Classes?
I honestly wouldn't use a language that doesn't has Classes unless I didn't had other options. Unless you're going to provide an alternative that works like or better than classes.

(Rate me dumb or whatever you want, but you still can't take away the fact that in a statically typed language classes or an equivalent alternative is fundamental)[/QUOTE]

I think the core concept of classes is flawed. "Behavior", "identity", and "data" are tied strongly together into a single concept of a class. In some cases, this is not an issue; but for a large majority of cases, having these ties makes programming even more difficult, because now you have to determine which data gets tied with which identity and behavior, which behavior gets tied with which identity and data, and which identity gets tied with which behavior and data. This makes developing large and complex systems even more complex than they already are. Separating "behavior", "identity", and "data" into separate concepts in my opinion makes the development process easier - however, the three can still be tied together in a looser manner than most object oriented languages. For example, [url=https://github.com/medcat/carbon/blob/ground/doc/language/color.ca]this is a code file[/url] for the general feel of how I want the language to be. It defines a module called "Image::Color" - this is its "identity". Inside of this module, there is a struct definition. This is its "data". This data is tied to the identity, because in order to reference the data structure outside of the module, you must use the module's name ("Image::Color"). Inside of this module, there are also function definitions. These are its "behavior". These functions are defined solely on the module, as a part of the module. For example, the "from-hex" function takes a string and returns a "Image::Color". You can call it from another module as "Image::Color.from-hex(...)". Carbon includes syntactic sugar, however. (If you've ever used lua, you might be familiar with this syntax.) You can define a function inside of a module that takes a first argument, "self". This makes the function operational on the data itself. So the "to-string" method can be called with "Image::Color.to-string(color)", or "color.to-string()". This is because the behavior of the module is loosely tied to the identity, and loosely tied to the data. This only works iff the first argument is defined to be "self".

I believe this would make developers more productive.

[QUOTE=Tamschi;49742274]Sure, I have no problem with criticism. It's necessary here anyway because it's difficult to know what the language actually is if there's contradictory documentation.

The issue with the C definitions/declarations at the start of a method is that you can't limit them to subscopes e.g. inside an [I]if[/I] branch, so you effectively enforce use of globals for those contexts.
This is imprecise and often leads to errors and hard to understand code, as far as I've seen. It also prevents automatic typing.

The issue with verbosity isn't the grammar structure of your language as much as the keywords.
[I]do[/I] and [I]end.[/I] make it cluttered while you could have used single characters or even just indentation for this (the latter of which would especially make sense if you want to enforce a consistent style).

[/quote]

There is no restriction on where a definition of a variable has to be; I just personally prefer them to be at the top.

The idea with the [i]do[/i]...[i]end[/i] is that it is repetitive across all parts of the language; function definitions use it, control statements use it, even data structure definitions use it. (The period terminates a top-level statement, by the way.) I am not a fan of significant whitespace, and there is no way I would be ok with putting it into Carbon. I was on the edge of using [i]{[/i] and [i]}[/i] for a while, but I prefer the [i]do[/i]...[i]end[/i] syntax.

[QUOTE=Tamschi;49742274]There are a few alternatives (prototypes, some kind of template system that creates true classes during compilation...) but with a statically typed languages not having them is really quite bad since they very efficiently help with certain kinds of problems.[/QUOTE]

See above.

[editline]14th February 2016[/editline]

As a side note, you can essentially replicate classes using what Carbon defines; it's just not a first-class thing in Carbon.

[laserpanda]

[vid]https://zippy.gfycat.com/MadDisguisedBluegill.webm[/vid]

I've got a bot that can shoot and a bot goalie now.

[GGG KILLER]

[QUOTE=Ac!dL3ak;49743081]-carbon long explanation-[/QUOTE]
I do use lua (mostly GMod) and at some point I had to make my own implementation of classes because I had the need of something like that.

From my point of view, you simply renamed Classes to something else and made them more loosely, but they're still classes (at least in my opinion, but I'm not a professional or experienced programmer as most of you here, so don't take my opinion too heavily).

[Ac!dL3ak]

[QUOTE=GGG KILLER;49743324]I do use lua (mostly GMod) and at some point I had to make my own implementation of classes because I had the need of something like that.

From my point of view, you simply renamed Classes to something else and made them more loosely, but they're still classes (at least in my opinion, but I'm not a professional or experienced programmer as most of you here, so don't take my opinion too heavily).[/QUOTE]

I will say that they do share some similarities, but the basic point is that they're not classes, and can't really be expected to act like classes.

Also, yeah, I've [url=https://gist.github.com/medcat/4d713713a11176ecdabf]had to write classes in lua[/url].

[GGG KILLER]

[QUOTE=Ac!dL3ak;49743399]I will say that they do share some similarities, but the basic point is that they're not classes, and can't really be expected to act like classes.

Also, yeah, I've [url=https://gist.github.com/medcat/4d713713a11176ecdabf]had to write classes in lua[/url].[/QUOTE]

Well, I think I have a better understanding of how it works, but what do you plan to call them? Modules as you stated before or something else?

(And my implementation of "classes" wasn't as advanced as yours, my knowledge of programming is surely not as advanced as yours)

[Ac!dL3ak]

[QUOTE=GGG KILLER;49743474]Well, I think I have a better understanding of how it works, but what do you plan to call them? Modules as you stated before or something else?[/QUOTE]

Yeah, so, they're modules, and modules can have associated data types. For example, a module could be a struct or an enum, or just a typedef (as in C). Not all modules have associated data types, but all data types have associated modules. It makes more sense if you work with it a little bit, which is why an implementation of it is my top priority - that, and it makes it easier to prototype the language before setting it in stone.

[QUOTE=GGG KILLER;49743474](And my implementation of "classes" wasn't as advanced as yours, my knowledge of programming is surely not as advanced as yours)[/QUOTE]

Don't sell yourself short; I may just happen to have extensive knowledge of certain things, but still lack the basic functionalities in other things. (One of those things just happens to be art, of any kind, unless I'm writing a program to generate it.)

[Tamschi]

[QUOTE=Ac!dL3ak;49743081][...]

I believe this would make developers more productive.

[...][/QUOTE]

It doesn't. You're simply removing the convenience feature of behaviour variants implicitly tied to data structure instances, which is [I]massively[/I] helpful in certain cases.
In the unlikely case this catches on, I can guarantee you someone will implement it in a less standardised/harder to read fashion once they stumble across heterogeneously varying behaviour patterns often enough (See Lua and JS.), because it's massively annoying to do this otherwise.

[Ac!dL3ak]

[QUOTE=Tamschi;49743755]It doesn't. [b]You're simply removing the convenience feature of behaviour variants implicitly tied to data structure instances,[/b] which is [I]massively[/I] helpful in certain cases.
In the unlikely case this catches on, I can guarantee you someone will implement it in a less standardised/harder to read fashion once they stumble across heterogeneously varying behaviour patterns often enough (See Lua and JS.), because it's massively annoying to do this otherwise.[/QUOTE]

Actually, I'm not entirely. Behavior can still be tied to data, and that's the whole point; behavior doesn't have to be tied to data, however; because in some cases, it doesn't make sense for there to be a specific data structure for something to operate on. The point of the language is to allow flexibility in how data and behavior is represented.

Basically, I'm not saying that grouping behavior and data together does not have its benefits - in fact, Carbon allows that for the cases in which it is massively helpful as you say. What I am saying is that grouping behavior and data together for everything is more harmful than it is helpful.

This departure from the implicit tie between data and behavior actually takes its roots in C, which is in and of itself a good language. However, C is not perfect for every project, mainly because of the fact that so much of it requires you to take control. Carbon is designed to be close to C, but make it easier for a developer to write a program.

[Tamschi]

[QUOTE=Ac!dL3ak;49743823]Actually, I'm not entirely. Behavior can still be tied to data, and that's the whole point; behavior doesn't have to be tied to data, however; because in some cases, it doesn't make sense for there to be a specific data structure for something to operate on. The point of the language is to allow flexibility in how data and behavior is represented.

Basically, I'm not saying that grouping behavior and data together does not have its benefits - in fact, Carbon allows that for the cases in which it is massively helpful as you say. What I am saying is that grouping behavior and data together for everything is more harmful than it is helpful.

This departure from the implicit tie between data and behavior actually takes its roots in C, which is in and of itself a good language. However, C is not perfect for every project, mainly because of the fact that so much of it requires you to take control. Carbon is designed to be close to C, but make it easier for a developer to write a program.[/QUOTE]

You can do this in every single class-focused language by using static methods though.
Quite a few now support extension methods that are a bit like your "[I]self[/I]" arguments but more flexible too.

You're really not adding anything new to the table here, just removing convenience functionality compared to the status quo.

[editline]15th February 2016[/editline]

Does your language have support for behaviour variance at the same call site at all, or does that have to be bootstrapped each time? If not then you can't list "tying behaviour to data" as language feature.

[brianosaur]

I feel like you guys are arguing about the difference between OOP/Imperative language paradigm vs the functional paradigm. In OOP classes keep state (data) and method operate on that data. In functional programming languages, its simply data transformations and functional languages generally avoid keeping state at all costs. The main reason is for concurrency and distributed systems. If you dont have state, then you dont have problems with multiple people accessing the same resource.

[CmdrMatthew]

[QUOTE=Richy19;49733710]Has anyone here made a crossplatform (desktop/smartphone) game in C++?[/QUOTE] I messed around with making one using the Android NDK once. It worked pretty well, but I never really got anywhere with it. The biggest problems for me were just working with OpenGL (no multithreading....) rather than DirectX, and some random networking function behavioral oddities.

[Richy13]

Would you guys recommend not using the standard STL in c++ and instead going for say "[URL="https://github.com/electronicarts/EASTL"]EA STL[/URL]"? Or will the standard one, for the most part, be fine?

[WTF Nuke]

Unless you have a specific reason and have measurable improvements, then go ahead and use EA's STL. Otherwise, stick with the standard. Remember, although it is faster in some aspects, it is slower in others.

[Ac!dL3ak]

[QUOTE=Tamschi;49744076]You can do this in every single class-focused language by using static methods though.[/QUOTE]

That may be true, but the issue is that those types of languages have a class-first approach, which is not what Carbon is about. You still run into issues with tying behavior to identity and data, regardless of whether or not the method is static.

[QUOTE=Tamschi;49744076]Quite a few now support extension methods that are a bit like your "[I]self[/I]" arguments but more flexible too.[/QUOTE]

I'm not entirely sure what you're saying here; I'd have to see what you mean. My gut instinct tells me that we're not entirely on the same page about the [i]self[/i] functionality, though.

[QUOTE=Tamschi;49744076]You're really not adding anything new to the table here, just removing convenience functionality compared to the status quo.[/QUOTE]

It never really was [i]new[/i] to begin with; C has done this sort of thing for a long time now. I'm also attempting to design Carbon in such a way that it can do pretty much every other language can do, just as easily.

[QUOTE=Tamschi;49744076]Does your language have support for behaviour variance at the same call site at all, or does that have to be bootstrapped each time? If not then you can't list "tying behaviour to data" as language feature.[/QUOTE]

Again, I'm not sure what you're trying to say here. You'd have to give an example for me to understand your point.

[QUOTE=brianosaur;49744507]I feel like you guys are arguing about the difference between OOP/Imperative language paradigm vs the functional paradigm. In OOP classes keep state (data) and method operate on that data. In functional programming languages, its simply data transformations and functional languages generally avoid keeping state at all costs. The main reason is for concurrency and distributed systems. If you dont have state, then you dont have problems with multiple people accessing the same resource.[/QUOTE]

Yes and no. I like the functional paradigm, but I feel it's much harder to operate on than OOP. I will attempt to integrate some of the ideals from the functional paradigm into Carbon, but there's not really much I can do.

[Darwin226]

I haven't written a proper class in a about a year or so. In fact, the only time I've written a class in the last year was to simulate something else (like being forced to associate every function with a class in C#).

I don't really get what the whole deal is. It's not like you can't have objects without classes. The only thing you don't have is inheritance, but if your objects only contain data and not methods, why would you need them to inherit anything?

I don't know man. The only thing that mattered for me is that I can write what I want at the expression level without having to jump through hoops. Something that pretty much every modern language does pretty well.
That and an expressive type system that catches as much as possible before it lets me run code.

[Ac!dL3ak]

[QUOTE=Darwin226;49745980][B]I haven't written a proper class in a about a year or so.[/B] In fact, the only time I've written a class in the last year was to simulate something else (like being forced to associate every function with a class in C#).

I don't really get what the whole deal is. [B]It's not like you can't have objects without classes.[/B] The only thing you don't have is inheritance, but if your objects only contain data and not methods, why would you need them to inherit anything?

I don't know man. [B]The only thing that mattered for me is that I can write what I want at the expression level without having to jump through hoops.[/B] Something that pretty much every modern language does pretty well.
That and an expressive type system that catches as much as possible before it lets me run code.[/QUOTE]

This is exactly what Carbon is targeting. The "objects without classes" you reference is what I've been calling "data", and the methods on those classes is what I've been calling "behavior." (The classes themselves would be considered the "identity.") The only real language that I know of that allows this type of expressiveness is C.

Also, Carbon will have strong typing, and will complain as much as possible before it compiles your code, so you can catch errors.

[editline]15th February 2016[/editline]

Page king; have an old project that would look up methods/functions in Ruby for you: [url]https://github.com/medcat/ducky[/url]

[CmdrMatthew]

[QUOTE=Richy19;49745879]Would you guys recommend not using the standard STL in c++ and instead going for say "[URL="https://github.com/electronicarts/EASTL"]EA STL[/URL]"? Or will the standard one, for the most part, be fine?[/QUOTE] Standard STL is fine for the most part, I just wouldn't use it in very performance critical areas. An example for what to not use it would be world data storage in a voxel engine.
The main problem with it is that it can be incredibly slow in debug mode, but that's rarely an issue.

[WTF Nuke]

You should be using debug mode for debugging, not for playing around with things.

[Darwin226]

[QUOTE=Ac!dL3ak;49746033]The only real language that I know of that allows this type of expressiveness is C.[/QUOTE]

Pretty much any vaguely functional language allows this.

[Ac!dL3ak]

[QUOTE=Darwin226;49746076]Pretty much any vaguely functional language allows this.[/QUOTE]

I don't know many functional languages :~)

[jonnopon3000]

[QUOTE=WTF Nuke;49746061]You should be using debug mode for debugging, not for playing around with things.[/QUOTE]

Debug mode is the absolute best way for anyone to learn what a particular program is doing, and I'll fight to the death on that.
My lecturers propose a lot of long-winded methods; reading precisely line-by-line; decorating code with print statements; halting program execution by returning values where not normally necessary...while these are all good methods of inspecting your program at run-time, I find it infuriating that they're not talking about debugging and breakpoints.

In my opinion, all three of the aforementioned methods of understanding are superseded by breaking the code at runtime and zoning in on the areas you really need to "get." This way you can naturally read line-by-line - but in explicit execution order rather than written order to to avoid confusion - and "print" (see) variables and their values in action.

I fully understand why a lecturer might encourage their students to go and [I]just read the bloody code[/I] in effort to help them understand it, but it doesn't prepare you at all for the actual requirements of a programmer, nor give you the opportunity to use the tools that every other programmer uses.

Probably waffled off-topic, just needed that off my chest. [I]University is seriously disappointing me[/I]