
Cone Programming Langauge - adamnemecek
http://cone.jondgoodwin.com
======
trishume
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.

~~~
jondgoodwin
That's a fair critique, and I will edit the website to make that disconnect
between current reality and aspiration clearer (more than the disclaimer I
have on the home page). Because there is so much left to do, I have made no
effort to market the language for any sort of use. So, I got caught flat-
footed that a website I am still building up piece by piece, primarily for
personal clarity and private communications, has gotten premature publicity. I
will adjust accordingly.

~~~
Camto
>I have made no effort to market the language for any sort of use.

Didn't you say it was mainly for the 3d web or something?

~~~
jondgoodwin
Yes, but that's not what I meant in that quote. Cone is not ready for any use
_right now_. So, I am making no effort to market it right now. When it is at
least MVP (at least a year or more away), I will get more serious about
marketing, including especially for 3D web.

------
mpoteat
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.

~~~
jondgoodwin
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.

------
joemccall86
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
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.

------
alkonaut
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
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 ..).

------
0xDEEPFAC
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
> _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
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?

~~~
coldtea
> _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
> 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

~~~
coldtea
> _Verbosity describes a programs behavior without implied knowledge thus a
> reader of some code will understand exactly what is meant._

Readability is not just about "understanding what is meant if you take the
time". It's also about each piece of code being easy to scan and understand to
find what you need. Devs have to scan whole projects to find what happens
where, and there's a balance between cryptic very succinct statements and
getting lost in expanded verbosity.

Verbosity hurts that by making less code fit on your screen, the code having
more stuff that's needed to convey the meaning, etc. You get lost in the extra
details, and have more baggage to keep in mind.

It's the difference between saying, e.g.: "Yeah", and "I am indeed craving
something savory with lots of melted curdled milk and processed pork cuts, and
I believe that we can immediately proceed with the thing that we were just now
discussing to do".

Which is one is the more "readable" answer to "Wanna go for a pizza?".

~~~
jondgoodwin
Very well said. This is very much what I am after. Some _common_ idioms in
Rust or C++ just feel unnecessarily verbose to me (e.g.,
`<exp>.unwrap().borrow_mut()`), and I am looking for straightforward ways,
often borrowed from other languages, to express the same intent more
succinctly and clearly.

