Items for 1.0
Michael Muller
essential for 1.0. I'll probably copy these onto a wiki page, but
let's start with an e-mail thread.
In the interests of providing a conceptual framework, let me start by
stating (or restating) a few things formally:
Crack 1.0 is important as a compatibility baseline: the main thing it
is providing is the guarantee that if you write code that works for
crack 1.x, it will also work for crack 1.y where y >= x. We won't
break compatibility again until 2.0.
I'm defining compatibility at the source code level, and based on the
behavior of working code. So the implications of compatibility are:
- Code written for 1.x will work the same under 1.y
- Code written using the libraries distributed with 1.x will work the
same under 1.y
- Extensions written for 1.x will continue to work (possibly after
recompile) for 1.y
Likewise, we will not extend compatibility to other kinds of interfaces:
- intermediate files (.bc, executables) generated by 1.x will not
necessarily be compatible with those generated by 1.y
- Code that is erroneous under 1.x will not necessarily be erroneous
(or display the same error) under 1.y
- Extensions compiled and linked for 1.x will not necessarily run with 1.y
Given these ground-rules, the criteria for whether a feature is
essential for 1.0 is:
1) the feature is important enough to want to have in 1.x, before we
re-iterate over the language design for 2.0.
2) there is a test case that will break or behave differently if we
introduce the feature.
So for example, one feature we need for 1.0 is: "disallow second order imports"
The test case for this is:
module a: import y x;
module b: import a x; # imports x from y _through_ b
Likewise, "constructor inheritence" (example: class A { oper init(int
x) {} } class B : A {} b := B(100)) is not essential for 1.0 because
although I consider it important enough to have before 2.0, I haven't
been able to identify a test case that breaks or behaves differently
once we implement it.
So, the items that I see as essential for 1.0 follow. I've included
their test cases.
- modules out of exp, stable apis
import crack.exp.cmdline CmdLine;
- disallow second order imports
module a: import y x;
module b: import a x;
- private conventions
class A { int __i; } A().__i;
- extension API changes for member access
[code that uses the existing api for member access]
- scoped annotations
void foo() { @define mac() { foo(); } }
@mac()
- pure virtual functions
class Foo : Writer {} # doesn't implement write()
- special reserved words: module, lambda, alias?
lambda = 1;
- constant variables
true = 1;
- constant folding?
uint64 i = ~0; # on 32 bit int, i = 2^32-1, not 2^64-1
- Interfaces converted to use "oper to" for cross-casting:
Writer w = createWriter(); w.getObject();
Let me also point out: this doesn't preclude us from adding other cool
stuff to 1.0. These are just the features that I consider essential
for 1.0, and they're going to be my priorities over the next few
months until we complete the 1.0 release.
Shannon Weyrick
bring up non-code plans for 1.0. By that I mean, what we can plan on
doing for the 1.0 release to make it easy for people to:
1) know that crack exists
2) understand what it is, how it's different from other languages, and
why they may want to try it
3) install and get running
4) understand how to use it
5) provide us feedback on suggestions and problems
For 2, it would be great if we could continue getting some benchmark
scripts together, and maybe some unique examples of programs you can
write in crack that you can't in popular scripting languages.
For 3, we were recently discussing on IRC that we should have a
repository setup for Ubuntu based packages (using the LLVM 2.9
packages that should be in the next Ubuntu release).
For 4, I think some tutorials and introductory material from the
perspective of "I'm a Foo programmer, how do I get started with crack"
where Foo is likely C/C++, Java, Python, PHP
I also always liked the idea of typing in little test programs online,
as they have on the llvm.org and golang.org. In general, I also think
our main web page should be more friendly to casual developers once we
hit 1.0.
Other ideas?
Shannon
Conrad Steenberg
somewhere, in addition to the project page.
Look at e.g. http://haxe.org/ or http://www.ruby-lang.org/en/
And aim to be simpler than http://python.org ;-)
I'll look around on some of the language comparison sites for simple
benchmarks (shorter than those on http://shootout.alioth.debian.org/).
Shannon Weyrick
<conrad.s...@gmail.com> wrote:
> I think we should have a separate "pretty" page for the language
> somewhere, in addition to the project page.
>
> Look at e.g. http://haxe.org/ or http://www.ruby-lang.org/en/
>
> And aim to be simpler than http://python.org ;-)
>
Yes, agreed. We've actually already got the separate pretty page
(http://crack-lang.org/), it just ain't pretty yet :)
Michael Muller
> On Thu, Jul 28, 2011 at 11:53 AM, Conrad Steenberg
> <conrad.s...@gmail.com> wrote:
>> I think we should have a separate "pretty" page for the language
>> somewhere, in addition to the project page.
>>
>> Look at e.g. http://haxe.org/ or http://www.ruby-lang.org/en/
>>
>> And aim to be simpler than http://python.org ;-)
>>
>
> Yes, agreed. We've actually already got the separate pretty page
> (http://crack-lang.org/), it just ain't pretty yet :)
The prototype is prettier: http://crack-lang.org/stage/
Or at least I think it is :-)
It needs an RSS aggregator to pull the latest news from the official
blog. Ideally one written in crack.
Michael Muller
On Jul 28, 2011 11:37 AM, "Shannon Weyrick" <wey...@mozek.us> wrote:
>
> No comment on the 1.0 code plans, sounds great. However I did want to
> bring up non-code plans for 1.0. By that I mean, what we can plan on
> doing for the 1.0 release to make it easy for people to:
>
> 1) know that crack exists
> 2) understand what it is, how it's different from other languages, and
> why they may want to try it
> 3) install and get running
> 4) understand how to use it
> 5) provide us feedback on suggestions and problems
All good points. To be clear, my post, and my priorities, mainly concern features that are essential from the perspective of keeping our promise of compatibility after 1.0 while allowing us to grow. This, to me, is priority 1. I haven't touched upon the question of what we need to do for Crack 1.0 to be successful in the way we want it to, but that doesn't mean this is unimportant to me.
For my own part, as I've said, I aim to start evangelizing more, which I think addresses much of what you're suggesting. If you can think of any good venues, let me know.
There is also the issue of certain features that, while not essential for compatibility, are extremely important from the perspective of delivering something truly awesome for what we hope will be a highly visible 1.0 release. The "bitcode caching" feature comes to mind: while not essential for compatibility, this is something that can be huge from the perspective of a user trying Crack for the first time. I can totally see this making the difference between "hmmph. No big deal." and "OMG, this rocks!" The importance of making the language live up to its name for 1.0 is not lost on me :-).
Shannon Weyrick
> On Jul 28, 2011 11:37 AM, "Shannon Weyrick" <wey...@mozek.us> wrote:
>
>>
>> No comment on the 1.0 code plans, sounds great. However I did want to
>> bring up non-code plans for 1.0. By that I mean, what we can plan on
>> doing for the 1.0 release to make it easy for people to:
>>
>> 1) know that crack exists
>> 2) understand what it is, how it's different from other languages, and
>> why they may want to try it
>> 3) install and get running
>> 4) understand how to use it
>> 5) provide us feedback on suggestions and problems
>
> All good points. To be clear, my post, and my priorities, mainly concern
> features that are essential from the perspective of keeping our promise of
> compatibility after 1.0 while allowing us to grow. This, to me, is priority
> 1. I haven't touched upon the question of what we need to do for Crack 1.0
> to be successful in the way we want it to, but that doesn't mean this is
> unimportant to me.
>
> For my own part, as I've said, I aim to start evangelizing more, which I
> think addresses much of what you're suggesting. If you can think of any
> good venues, let me know.
>
Good ol' Slashdot would be cool, when we're ready...
> There is also the issue of certain features that, while not essential for
> compatibility, are extremely important from the perspective of delivering
> something truly awesome for what we hope will be a highly visible 1.0
> release. The "bitcode caching" feature comes to mind: while not essential
> for compatibility, this is something that can be huge from the perspective
> of a user trying Crack for the first time. I can totally see this making
> the difference between "hmmph. No big deal." and "OMG, this rocks!" The
> importance of making the language live up to its name for 1.0 is not lost on
> me :-).
>
Agreed, I think we need the caching for 1.0. In fact, apart from the
list you mentioned, I'd say that's top priority.
A couple of easy extensions wouldn't hurt either. I'm thinking it
wouldn't be too hard to do a few popular C libraries, like MySQL or
SQLite, mcrypt, ...
Isaac Gouy
On Jul 28, 8:53 am, Conrad Steenberg <conrad.steenb...@gmail.com>
wrote:
> somewhere, in addition to the project page.
>
>
> And aim to be simpler thanhttp://python.org;-)
> I'll look around on some of the language comparison sites for simple
> benchmarks (shorter than those onhttp://shootout.alioth.debian.org/).
Conrad Steenberg
>
> On Jul 28, 8:53 am, Conrad Steenberg <conrad.steenb...@gmail.com>
> wrote:
> >
> > I'll look around on some of the language comparison sites for simple
> > benchmarks (shorter than those onhttp://shootout.alioth.debian.org/).
>
>
> Less code than the programs shown at the benchmarks game? Really? ;-)
Yeah, really: you'd be surprised at how effective it is to show someone
who uses Python how fast a simple empty loop, or printf loop in Crack
is.