7 ms·

Cone Programming Langauge

79 points by adamnemecek 8y ago

0xDEEPFAC 8y ago
Very cool language. It is good to see people still trying to innovate! However, the marketing seems like a contradiction - concise and readable are antithetical as well as "flexible typing" and type safe. I am left confused.. what paradigms does it employ? Imperative?
- coldtea 8y ago
  >concise and readable are antithetical Not really. If anything concise core can be much easier to read. The key is to discard BS boilerplate and ceremonial code, and have the intention of the code clearer in less lines. Python is far more readable than Java, for example, and far more concise. >as well as "flexible typing" and type safe Not if you support variant types and the like.
  - 0xDEEPFAC 8y ago
    Hmmm, you assume everyone understands that fn means function and that a void function is the same as a procedure. Everybody and their grandma can read Pascal and Ada, but abbreviated keywords and magical symbol require foreknowledge. And the more abbreviated, the more you will have to continuously look up things in the reference manual until they get cemented. > Not if you support variant types and the like. Not sure what you mean here - discriminant unions? classes?
    - jerf 8y ago
      "And the more abbreviated, the more you will have to continuously look up things in the reference manual until they get cemented." But something like "fn" isn't going to be a problem, because you're going to use it a dozen times before you finish the tutorial. Symbols are also OK in proportion to their commonality. Rarely used symbols become more problematic. This can be mitigated if there's a clean way to find documentation for them, though you can't get around the problem that google is unlikely to ever be useful for them.
      - Verdex 8y ago
        This is actually a property in information theory. Often used symbols should have short representations and rarely used symbols should have long representations. People have a habit of automatically doing this. It's why pretty much every niche field or industry develops jargon and three letter acronyms. Everyone gets tired of saying the whole thing so it's shortened. Not only does it just make sense that things like "fn" are going to be okay, but there's also some mathematical backing as to why it's okay.
        longstation 8y ago
        This property reminds me of Huffman code.
        Verdex 8y ago
        Yup. If you checkout the wikipedia page on huffman coding you'll see that David Huffman got his idea while in an information theory class with Robert Fano. Fano had worked with Shannon (the inventor of information theory) to develop a similar coding, but Huffman was able to develop a provably better system.
        0xDEEPFAC 8y ago
        Sure, but my point is that "Okay" things are not as good as "Great" things like spelled out type definitions. For example look at this object declaration in Ada - you may not know Ada and the symbols associated with pointers but you will know exactly what it is: type My_Arr is array (1..10) of Natural; My_Fancy_Obj : not null access My_Arr := new My_Arr'(1..4 => 0, others => 1234);
        DonaldPShimoda 8y ago
        type My_Arr is array (1..10) of Natural; Speaking as someone who works in PL research (but keeping in mind that I'm still low on the totem pole, i.e., I don't have a PhD)... I don't know what this is supposed to mean. Based on the first word being `type`, I'm guessing this is a type declaration for a new type named `My_Arr`. And `is array` makes me think that this is an array of some kind. But then I get to `(1..10)` and I'm lost. Is this a dependent type? Is it an initialized value? I'm genuinely not sure. The `of Natural` at the end tells me that `My_Arr` is an array of natural numbers, I guess, but I'm lost on the `(1..10)` bit. I figure it could either be: a) `My_Arr` is the type of arrays of natural numbers of length 1..10 (is that inclusive? exclusive? unsure) or b) `My_Arr` is the type of arrays consisting of only the natural numbers 1..10 (again, unsure whether inclusive or exclusive) Or I guess it could be something else, though I'm not sure exactly what that'd be. My_Fancy_Obj : not null access My_Arr := ... I guess this is defining an... object? It can't be a type declaration because there's no `type` keyword (which I had previously assumed to indicate the beginning of a type declaration). But this syntax is strange. I assume `My_Fancy_Obj` is the name of the instance in question, so `x : y := z` must mean "create an object named x of type y and store the result of evaluating z there". (I'm guessing based on what I know of other languages.) `not null access` is weird to me. I mean, "not null" is straightforward enough (`My_Fancy_Obj` can never have a null value), but I'm not sure what "access" means. Is it a reference type? Like a pointer? Or something? I dunno what else it could be. So `My_Fancy_Obj` is really a box (reference/pointer) containing a `My_Arr`, and it can never be null. Now... looking at the initialization... ... new My_Arr'(1..4 => 0, others => 1234); I'm so lost haha. I guess the values 1..4 (inclusive? exclusive? shrug) are initialized to zero. And the "others" are initialized to... the value 1,234? I guess? But how long is this array? The presence of an `others` keyword (I'm assuming it's a keyword, or an initialization argument I suppose) tells me that it must be obvious to the interpreter/compiler exactly how many values there are. So... I guess that means `My_Arr` is actually an array of exactly length 10? Why on earth would they have the `array (1..10)` syntax for that, instead of like `array 10` or `array(10)` or something. That's confusing. So I guess we end up with something like `[0, 0, 0, 0, 1234, 1234, 1234, 1234, 1234, 1234]`? Anyway, this example did not achieve your desired result — at least, not from my perspective.
    - coldtea 8y ago
      >Hmmm, you assume everyone understands that fn means function and that a void function is the same as a procedure. No, I don't assume that. But I think that that's irrelevant. People didn't know "def" means function in Python or Scala either, but they learn it on the first day and don't have a readability problem with it. Very basic keywords like "fn" are not the things that make a language unreadable, nor is calling the keyword "fn" instead of "function". Those are memorized in a day or so and you're done with it. It's other things that make languages unreadable (too many sigils, overloaded operators or keywords in different contexts (C++, Perl), single letter operators (e.g. APL), too low level, too much verbosity, etc. In any case, whether a person that first encounter a language immediately recognizes what a keyword means is not what makes the language readable. It's how readable it is to its programmers, after they know the language and have written code in it that matters. Familiar != readable. >Everybody and their grandma can read Pascal and Ada, but abbreviated keywords and magical symbol require foreknowledge. And almost everybody and their grandma dislike their syntax (especially Ada's), and would prefer something less verbose. >And the more abbreviated, the more you will have to continuously look up things in the reference manual until they get cemented. It's after such basics "get cemented" that readability comes into play, not before. If someone has to look after 2-3 days with the language what "fn" means or how to declare a function (and similarly, "def" in Python/Scala, etc), they have some serious memory issues. (Btw, Rust, Clojure, and others also use "fn"). >Not sure what you mean here - discriminant unions? classes? Yes, aka variant, aka tagged union, aka sum type...
      - 0xDEEPFAC 8y ago
        > overloaded operators or keywords in different contexts (C++, Perl) Woa there, ever look at vector math libraries in C - horribly unreadable and ugly. > too much verbosity Verbosity describes a programs behavior without implied knowledge thus a reader of some code will understand exactly what is meant. I disagree that the definition of readability is all about how quickly you can skim source code - and ew too many words. > And almost everybody and their grandma dislike their syntax (especially Ada's), and would prefer something less verbose. Well, they were objectively designed to readability based on studies of other languages (at least Ada). And hey, I like it but I guess I am biased : P
- jondgoodwin 8y ago
  Cone is an imperative, multi-paradigmatic language in the family of systems programming languages (C, C++, Rust, D). It is fundamentally statically-typed. However, a language that is too rigidly typed can sometimes degrade programmer productivity. Abstractions like variant types and various forms of type polymorphism can improve code flexibility and reuse, which is why I plan for Cone to include these features (the home page has a link to a page that describes this in more detail). High-level attributes of a language are always hard to get right, because terms mean different things to different people, but several responders do a better job than I did of explaining why concise and readable don't necessarily have to be contradictory goals, at least for me. My primary aim here is that code be maintainable. By concise, I am actually far more focused on how much of a function's logic can fit readably on the editor window without scrolling than I am the size of keywords. Certain common C++/Rust patterns feel unnecessarily verbose to me (e.g., borrowing a reference in Rust), and I am trying to incorporate syntactic patterns from a number of other languages that I feel encode the same intent consistently in a way that a programmer familiar with Cone will be able to process and edit more quickly. Of course, that's always a judgement call...
  - 0xDEEPFAC 8y ago
    As a language designer myself I truly do applaud your effort. I am just a fellow skeptical human who loves strongly typed languages! Keep it up, I will be following the progress. > ...focused on how much of a function's logic can fit readably on the editor window without scrolling than I am the size of keywords This seems like a silly reason, we have large widescreen high res monitors - C's curly braces were invented to fit inside 70 char by 90 char terminals. Lets just be honest with ourselves and say its because its what people generally like and/or are used to these days : ) I mean Pascal/Ada isn't all that bad - it just not trendy https://github.com/AdaDoom3/AdaDoom3/blob/master/Engine/neo-engine-renderer.adb https://github.com/AdaDoom3/AdaDoom3/blob/master/Engine/neo-...
    - jondgoodwin 8y ago
      Thanks. I always welcome feedback and take it seriously.
trishume 8y ago
While I like a lot of the ideas described on the website, I don’t like how they’re written in the present tense and like Cone can currently do all these things when in fact they’re just aspirations and aren’t even designed in detail. I had to go to a file in the Github to figure out what actually exists. I support your quest but actually implementing the language is the hard part. Languages like Rust don’t even mention features on their websites even when they have working implementations that just aren’t stable yet, it would be nice if Cone’s gave a clear picture of what exists and what’s an aspiration.
- 0xDEEPFAC 8y ago
  I disagree, a language is merely a standard defined by reference documentation and sometimes certified by ANSI and the like. The fact that things are documented means thought has been put into the design, but... yea unimplemented things should be labeled
  - ModernMech 8y ago
    I think it used to be the case that a language and it's implementation were considered separate things. Today it seems like they are conflated to the point where people take the position that if it's not implemented, it's not actually a language. This view discounts the great languages of the past that were never implemented due to platform immaturity.
    - pushpop 8y ago
      I think the issue was more that languages often used to have multiple implementations which differed and no real standard beyond the de facto (whichever was most commonly used). You saw this with the variations of BASIC on the micro computers, the different Pascal and C compilers of the 70s and 80s etc. But even back then, languages without a compiler were still nothing more than an academic exercise which entertained a comparatively few of the overall engineers around at that time. So I don’t think much has changed in that regard aside the expectation that a language should now have a reference implementation. And even then that’s not always the case (eg Perl 6).
mpoteat 8y ago
The language description declares it is safe, but since you can dereference raw pointers, the language is not memory safe. Maybe it should be made clear that you are not claiming memory safety.
- Camto 8y ago
  On it's own, pointer dereffing is not unsafe. Null pointers and out of bounds dereffing is what causes problems. Unless you're in an unsafe block I don't think Cone allows for arbitrary pointer shenanigans like C does.
- jondgoodwin 8y ago
  It is memory safe in the same way as Rust is. Rust allows you to de-reference a raw pointer, but only within an explicitly de-marked `unsafe` block. Cone will require a similar explicit mechanism. If you want the compiler to check your code for memory safety, don't use this mechanism. If you do use it, the responsibility for safety within rests on you, the programmer.
alkonaut 8y ago
No matter how enthusiastic the creator is about a “3D web” I doubt putting it as a top design goal does the language any good (I nearly stopped reading right there). Perhaps as the language seems to be influenced by Rust it would be good to outline what specific differences it has to Rust in terms of goals.
- jondgoodwin 8y ago
  A summary of key differences from Rust: A richer collection of build-in memory management strategies (e.g., tracing GC), Pony-inspired permissions (esp. safe shared, mutable), structural subtyping (as well as nominal), and a bunch of features intended to improve ease-of-use and productivity. At some point, I will write up a page on my web site to explain Cone better for someone coming from Rust (or C++ or ..).
joemccall86 8y ago
Interestingly, the logo is a direct copy of UCF's academic logo: https://www.ucf.edu/brand/brand-assets/logo-identity-system/ https://www.ucf.edu/brand/brand-assets/logo-identity-system/. I wonder if there is a connection.
- jondgoodwin 8y ago
  There is no connection. I was unaware of the similarity to UCF's logo until recently. It is something I will need to replace, as much as I like how it looks.

79 points by adamnemecek 8y ago

Very cool language. It is good to see people still trying to innovate! However, the marketing seems like a contradiction - concise and readable are antithetical as well as "flexible typing" and type safe. I am left confused.. what paradigms does it employ? Imperative?

coldtea 8y ago
>concise and readable are antithetical Not really. If anything concise core can be much easier to read. The key is to discard BS boilerplate and ceremonial code, and have the intention of the code clearer in less lines. Python is far more readable than Java, for example, and far more concise. >as well as "flexible typing" and type safe Not if you support variant types and the like.
- 0xDEEPFAC 8y ago
  Hmmm, you assume everyone understands that fn means function and that a void function is the same as a procedure. Everybody and their grandma can read Pascal and Ada, but abbreviated keywords and magical symbol require foreknowledge. And the more abbreviated, the more you will have to continuously look up things in the reference manual until they get cemented. > Not if you support variant types and the like. Not sure what you mean here - discriminant unions? classes?
  - jerf 8y ago
    "And the more abbreviated, the more you will have to continuously look up things in the reference manual until they get cemented." But something like "fn" isn't going to be a problem, because you're going to use it a dozen times before you finish the tutorial. Symbols are also OK in proportion to their commonality. Rarely used symbols become more problematic. This can be mitigated if there's a clean way to find documentation for them, though you can't get around the problem that google is unlikely to ever be useful for them.
    - Verdex 8y ago
      This is actually a property in information theory. Often used symbols should have short representations and rarely used symbols should have long representations. People have a habit of automatically doing this. It's why pretty much every niche field or industry develops jargon and three letter acronyms. Everyone gets tired of saying the whole thing so it's shortened. Not only does it just make sense that things like "fn" are going to be okay, but there's also some mathematical backing as to why it's okay.
      - longstation 8y ago
        This property reminds me of Huffman code.
        Verdex 8y ago
        Yup. If you checkout the wikipedia page on huffman coding you'll see that David Huffman got his idea while in an information theory class with Robert Fano. Fano had worked with Shannon (the inventor of information theory) to develop a similar coding, but Huffman was able to develop a provably better system.
      - 0xDEEPFAC 8y ago
        Sure, but my point is that "Okay" things are not as good as "Great" things like spelled out type definitions. For example look at this object declaration in Ada - you may not know Ada and the symbols associated with pointers but you will know exactly what it is: type My_Arr is array (1..10) of Natural; My_Fancy_Obj : not null access My_Arr := new My_Arr'(1..4 => 0, others => 1234);
        DonaldPShimoda 8y ago
        type My_Arr is array (1..10) of Natural; Speaking as someone who works in PL research (but keeping in mind that I'm still low on the totem pole, i.e., I don't have a PhD)... I don't know what this is supposed to mean. Based on the first word being `type`, I'm guessing this is a type declaration for a new type named `My_Arr`. And `is array` makes me think that this is an array of some kind. But then I get to `(1..10)` and I'm lost. Is this a dependent type? Is it an initialized value? I'm genuinely not sure. The `of Natural` at the end tells me that `My_Arr` is an array of natural numbers, I guess, but I'm lost on the `(1..10)` bit. I figure it could either be: a) `My_Arr` is the type of arrays of natural numbers of length 1..10 (is that inclusive? exclusive? unsure) or b) `My_Arr` is the type of arrays consisting of only the natural numbers 1..10 (again, unsure whether inclusive or exclusive) Or I guess it could be something else, though I'm not sure exactly what that'd be. My_Fancy_Obj : not null access My_Arr := ... I guess this is defining an... object? It can't be a type declaration because there's no `type` keyword (which I had previously assumed to indicate the beginning of a type declaration). But this syntax is strange. I assume `My_Fancy_Obj` is the name of the instance in question, so `x : y := z` must mean "create an object named x of type y and store the result of evaluating z there". (I'm guessing based on what I know of other languages.) `not null access` is weird to me. I mean, "not null" is straightforward enough (`My_Fancy_Obj` can never have a null value), but I'm not sure what "access" means. Is it a reference type? Like a pointer? Or something? I dunno what else it could be. So `My_Fancy_Obj` is really a box (reference/pointer) containing a `My_Arr`, and it can never be null. Now... looking at the initialization... ... new My_Arr'(1..4 => 0, others => 1234); I'm so lost haha. I guess the values 1..4 (inclusive? exclusive? shrug) are initialized to zero. And the "others" are initialized to... the value 1,234? I guess? But how long is this array? The presence of an `others` keyword (I'm assuming it's a keyword, or an initialization argument I suppose) tells me that it must be obvious to the interpreter/compiler exactly how many values there are. So... I guess that means `My_Arr` is actually an array of exactly length 10? Why on earth would they have the `array (1..10)` syntax for that, instead of like `array 10` or `array(10)` or something. That's confusing. So I guess we end up with something like `[0, 0, 0, 0, 1234, 1234, 1234, 1234, 1234, 1234]`? Anyway, this example did not achieve your desired result — at least, not from my perspective.
  - coldtea 8y ago
    >Hmmm, you assume everyone understands that fn means function and that a void function is the same as a procedure. No, I don't assume that. But I think that that's irrelevant. People didn't know "def" means function in Python or Scala either, but they learn it on the first day and don't have a readability problem with it. Very basic keywords like "fn" are not the things that make a language unreadable, nor is calling the keyword "fn" instead of "function". Those are memorized in a day or so and you're done with it. It's other things that make languages unreadable (too many sigils, overloaded operators or keywords in different contexts (C++, Perl), single letter operators (e.g. APL), too low level, too much verbosity, etc. In any case, whether a person that first encounter a language immediately recognizes what a keyword means is not what makes the language readable. It's how readable it is to its programmers, after they know the language and have written code in it that matters. Familiar != readable. >Everybody and their grandma can read Pascal and Ada, but abbreviated keywords and magical symbol require foreknowledge. And almost everybody and their grandma dislike their syntax (especially Ada's), and would prefer something less verbose. >And the more abbreviated, the more you will have to continuously look up things in the reference manual until they get cemented. It's after such basics "get cemented" that readability comes into play, not before. If someone has to look after 2-3 days with the language what "fn" means or how to declare a function (and similarly, "def" in Python/Scala, etc), they have some serious memory issues. (Btw, Rust, Clojure, and others also use "fn"). >Not sure what you mean here - discriminant unions? classes? Yes, aka variant, aka tagged union, aka sum type...
    - 0xDEEPFAC 8y ago
      > overloaded operators or keywords in different contexts (C++, Perl) Woa there, ever look at vector math libraries in C - horribly unreadable and ugly. > too much verbosity Verbosity describes a programs behavior without implied knowledge thus a reader of some code will understand exactly what is meant. I disagree that the definition of readability is all about how quickly you can skim source code - and ew too many words. > And almost everybody and their grandma dislike their syntax (especially Ada's), and would prefer something less verbose. Well, they were objectively designed to readability based on studies of other languages (at least Ada). And hey, I like it but I guess I am biased : P
jondgoodwin 8y ago
Cone is an imperative, multi-paradigmatic language in the family of systems programming languages (C, C++, Rust, D). It is fundamentally statically-typed. However, a language that is too rigidly typed can sometimes degrade programmer productivity. Abstractions like variant types and various forms of type polymorphism can improve code flexibility and reuse, which is why I plan for Cone to include these features (the home page has a link to a page that describes this in more detail). High-level attributes of a language are always hard to get right, because terms mean different things to different people, but several responders do a better job than I did of explaining why concise and readable don't necessarily have to be contradictory goals, at least for me. My primary aim here is that code be maintainable. By concise, I am actually far more focused on how much of a function's logic can fit readably on the editor window without scrolling than I am the size of keywords. Certain common C++/Rust patterns feel unnecessarily verbose to me (e.g., borrowing a reference in Rust), and I am trying to incorporate syntactic patterns from a number of other languages that I feel encode the same intent consistently in a way that a programmer familiar with Cone will be able to process and edit more quickly. Of course, that's always a judgement call...
- 0xDEEPFAC 8y ago
  As a language designer myself I truly do applaud your effort. I am just a fellow skeptical human who loves strongly typed languages! Keep it up, I will be following the progress. > ...focused on how much of a function's logic can fit readably on the editor window without scrolling than I am the size of keywords This seems like a silly reason, we have large widescreen high res monitors - C's curly braces were invented to fit inside 70 char by 90 char terminals. Lets just be honest with ourselves and say its because its what people generally like and/or are used to these days : ) I mean Pascal/Ada isn't all that bad - it just not trendy https://github.com/AdaDoom3/AdaDoom3/blob/master/Engine/neo-engine-renderer.adb https://github.com/AdaDoom3/AdaDoom3/blob/master/Engine/neo-...
  - jondgoodwin 8y ago
    Thanks. I always welcome feedback and take it seriously.

trishume 8y ago

While I like a lot of the ideas described on the website, I don’t like how they’re written in the present tense and like Cone can currently do all these things when in fact they’re just aspirations and aren’t even designed in detail. I had to go to a file in the Github to figure out what actually exists. I support your quest but actually implementing the language is the hard part. Languages like Rust don’t even mention features on their websites even when they have working implementations that just aren’t stable yet, it would be nice if Cone’s gave a clear picture of what exists and what’s an aspiration.

0xDEEPFAC 8y ago
I disagree, a language is merely a standard defined by reference documentation and sometimes certified by ANSI and the like. The fact that things are documented means thought has been put into the design, but... yea unimplemented things should be labeled
- ModernMech 8y ago
  I think it used to be the case that a language and it's implementation were considered separate things. Today it seems like they are conflated to the point where people take the position that if it's not implemented, it's not actually a language. This view discounts the great languages of the past that were never implemented due to platform immaturity.
  - pushpop 8y ago
    I think the issue was more that languages often used to have multiple implementations which differed and no real standard beyond the de facto (whichever was most commonly used). You saw this with the variations of BASIC on the micro computers, the different Pascal and C compilers of the 70s and 80s etc. But even back then, languages without a compiler were still nothing more than an academic exercise which entertained a comparatively few of the overall engineers around at that time. So I don’t think much has changed in that regard aside the expectation that a language should now have a reference implementation. And even then that’s not always the case (eg Perl 6).

mpoteat 8y ago

The language description declares it is safe, but since you can dereference raw pointers, the language is not memory safe. Maybe it should be made clear that you are not claiming memory safety.

Camto 8y ago
On it's own, pointer dereffing is not unsafe. Null pointers and out of bounds dereffing is what causes problems. Unless you're in an unsafe block I don't think Cone allows for arbitrary pointer shenanigans like C does.
jondgoodwin 8y ago
It is memory safe in the same way as Rust is. Rust allows you to de-reference a raw pointer, but only within an explicitly de-marked `unsafe` block. Cone will require a similar explicit mechanism. If you want the compiler to check your code for memory safety, don't use this mechanism. If you do use it, the responsibility for safety within rests on you, the programmer.

alkonaut 8y ago

No matter how enthusiastic the creator is about a “3D web” I doubt putting it as a top design goal does the language any good (I nearly stopped reading right there). Perhaps as the language seems to be influenced by Rust it would be good to outline what specific differences it has to Rust in terms of goals.

jondgoodwin 8y ago
A summary of key differences from Rust: A richer collection of build-in memory management strategies (e.g., tracing GC), Pony-inspired permissions (esp. safe shared, mutable), structural subtyping (as well as nominal), and a bunch of features intended to improve ease-of-use and productivity. At some point, I will write up a page on my web site to explain Cone better for someone coming from Rust (or C++ or ..).

joemccall86 8y ago

Interestingly, the logo is a direct copy of UCF's academic logo: https://www.ucf.edu/brand/brand-assets/logo-identity-system/ https://www.ucf.edu/brand/brand-assets/logo-identity-system/. I wonder if there is a connection.

jondgoodwin 8y ago
There is no connection. I was unaware of the similarity to UCF's logo until recently. It is something I will need to replace, as much as I like how it looks.