[go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful.

On Friday, May 17, 2013 3:23:13 PM UTC-4, Sod Almighty wrote:

Hi all.

I'm trying to implement a Linq-alike for Go, mainly for practice but also
because I find Enumerables really easy to work with. Unfortunately, I have
hit several walls, all due to missing features in the language.


1. *Generics.* Yeah, I know Google doesn't like them. But how else are
you gonna define a function that takes a parameter of type T along with a
function that takes a T and returns a T? Answer: You can't. It must take an
interface{} and a function that takes an interface{} and returns an
interface{}. And then you can't call this function and pass in an int and a
function taking an int and returning an int. No, you have to write a
specifically non-type-safe function and pass *that* in, even if you
had a perfectly good int->int function kicking around. Madness!

2. *Overloading.* I decided to start by writing Ana, Cata and Bind, a
la MinLINQ. Unfortunately, due to the lack of generics, I need to write an
Ana() that deals with interface{}s, along with specialised versions for
ints, strings and floats. But... you can't have functions with the same
name and different parameters, so that's out too.

3. *Methods. *So, I figured I'd make each overload of Ana be a method
on the relevant type, but the compiler spits out "cannot define new methods
on non-local type int". So I can't do that either.


Don't get me wrong: It's great to see the number of modern native-compiled
languages exceed "1", but seriously guys, how's a fellow supposed to get
anything done without generics?

I want a function like this:

func Ana(seed T, condition func(T) bool, next func(T) T) FEnumerable<T> {
... code ...
}

Is that really so unreasonable? Are you seriously telling me that writing
out loops and such at the call site is better than having a reusable *
*cough** "class library"? I don't want to be declaring lists and slices
all over the place every time I want to query something. I want to simply
say "From(something).Where(filter).Select(transformation)". You can do that
in C++, C#, D, VB.NET and pretty much any other modern language. If
you're going to have types, you must also have generics. Period. Otherwise
we're just back in the dark ages casting everything back and forth, or
writing the same code over and over again.

Again, let me say that I'm not knocking Go specifically. I'm sick of being
locked into C++ whether I like it or not (yeah, I know there's D, but it's
riddled with bugs). But what use are "first-class functions" when you have
neither generics nor polymorphism? The whole point of first-class functions
is to plug specific *strongly-typed* sorting or filtering functionality
into an otherwise generic *untyped* process. In other words, the function
you're calling doesn't need to know or care what kind of objects its
dealing with, because you've provided a function object that can do the
type-specific bit of work. But here I can't, because a func(int)int won't
be accepted by a function expecting a func(interface{})interface{}.

On Friday, May 17, 2013 9:36:10 PM UTC+1, James Bardin wrote:
No one is likely to debate this with you:
http://golang.org/doc/faq#generics

There may be generics is the future, but in the meantime most of us are
happy with no generics vs poor generics.

On Fri, May 17, 2013 at 12:23 PM, wrote:
Generics. Yeah, I know Google doesn't like them. But how else are you gonna
define a function that takes a parameter of type T along with a function
that takes a T and returns a T? Answer: You can't. It must take an
interface{} and a function that takes an interface{} and returns an
interface{}. And then you can't call this function and pass in an int and a
function taking an int and returning an int. No, you have to write a
specifically non-type-safe function and pass that in, even if you had a
perfectly good int->int function kicking around. Madness!

On May 17, 2013 10:42 PM, "Ian Lance Taylor" wrote:
I'm not going to pretend that Go is good at this, because it's not.
But you actually can do this: http://play.golang.org/p/emiuPJwfCS .

Ian

--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On Friday, May 17, 2013 9:43:03 PM UTC+1, Aaron France wrote:
Troll detected

On Friday, May 17, 2013 4:55:25 PM UTC-4, Sod Almighty wrote:
Troll yourself. Didn't you read what I wrote? As I said, I'm in favour of
new native languages and would like to use Go, but I feel my objections are
valid. If you disagree, why not explain why you think generics aren't
necessary, rather than just sitting there and hurling insults for no reason.

On Friday, May 17, 2013 10:07:18 PM UTC+1, James Bardin wrote:
Oh geez, I was hoping a polite pointer to the FAQ (which covers
overloading too BTW) would be enough to prevent this usual progression.

On Fri, May 17, 2013 at 2:18 PM, Sod Almighty wrote:

People often tell me that. But, as I have no idea why, there's not a lot I
can do about it. I look at my original post, and I see a polite criticism
and a request for change. I insulted nobody, used no foul language, didn't
say the language sucked, and gave every impression that I liked it in
general and would appreciate some added functionality. All I wanted was a
sensible adult discussion.

It doesn't seem to matter how hard I try to be nice and polite, people
always jump down my throat and accuse me of being angry or antagonistic. I
really don't know why I bother.

On Friday, May 17, 2013 10:51:50 PM UTC+1, Ian Lance Taylor wrote:

Do you really not know? If this has occurred to you multiple times,
and it's not intentional, then perhaps you should investigate your
style of communication. Much as you said yourself farther down the
thread, if many people tell you something, then perhaps it is true.
Even if it's hard for you to see it yourself.

On Fri, May 17, 2013 at 3:21 PM, Sod Almighty wrote:

I have tried to comprehend why I seem to speak a different language to
everyone else on the planet; and have got precisely nowhere. I honestly
cannot see anything wrong with my original post. Granted, some of my other
posts have been a little snappish, but generally in response to unhelpful
posts. Occasionally, when someone is helpful, you will notice that I thank
them.

On Friday, May 17, 2013 11:38:12 PM UTC+1, Ian Lance Taylor wrote:

I encourage you to reflect on your post and how people respond to it.
It's not a matter of what you are trying to say. It's a matter of how
you say it.

I'm trying to say something not about what you are saying, but about
how you are saying it. You are responding by reasserting what you are
trying to say. That's not the point. It's not about the content.
It's about the presentation.

Am Samstag, 18. Mai 2013 00:51:23 UTC+2 schrieb Sod Almighty:
I get that. However, from my point of view, the content is 99% of the
message. If I say "people who use Go are idiots", well, that's rude. If I
say "Seriously? I can't even do *this?*" - well, in my native language,
incredulity at the limitations of a system does not equal an insult to the
people using it. I call my native language "English". Apparently it's not
the same as what everyone else is using, however.

Telling me that the presentation is important, while informative and
appreciated, doesn't actually enable me to do anything about it. I look at
my "presentation", as you call it, and see nothing wrong. (Except when I'm
replying to unhelpful posts, of course.) While I'm aware that the majority
of people in this world react badly to how I say things, I honestly can't
do anything about it. Or, at least, haven't been able to thus far. Given
that I'm in my thirties, I don't see that changing overmuch.

On Friday, May 17, 2013 11:59:47 PM UTC+1, Volker Dobler wrote:

You might want to try a Snickers. Or a weekend reflecting
what and why was said.

On Fri, May 17, 2013 at 3:59 PM, Sod Almighty wrote:
As an aside, can anyone explain to me why compilers are always written in
the languages they compile? The compiler for Red is to be re-written in Red
once the language is usable. The compiler for Rust is written in Rust, and
so on. I don't understand why this is important.

On Saturday, May 18, 2013 12:18:59 AM UTC+1, Ian Lance Taylor wrote:

It's normally done because 1) language developers tend to be compiler
writers, and tend to be interested in languages that are good for
writing compilers; 2) writing a compiler in a language ensures that
the language is powerful enough to write a reasonable complex program.

On Fri, May 17, 2013 at 3:51 PM, Sod Almighty wrote:

I get that. However, from my point of view, the content is 99% of the
message. If I say "people who use Go are idiots", well, that's rude. If I
say "Seriously? I can't even do this?" - well, in my native language,
incredulity at the limitations of a system does not equal an insult to the
people using it. I call my native language "English". Apparently it's not
the same as what everyone else is using, however.

On Saturday, May 18, 2013 12:15:49 AM UTC+1, Ian Lance Taylor wrote:
On Fri, May 17, 2013 at 3:51 PM, Sod Almighty wrote:

You don't intend an insult. But you are implying that the system is
not merely deficient but obviously and fragrantly deficient.

On Fri, May 17, 2013 at 4:32 PM, Sod Almighty wrote:

I think perhaps you mean "flagrantly deficient". I didn't say anything about
how it smells.

On Saturday, May 18, 2013 1:07:04 AM UTC+1, Ian Lance Taylor wrote:

Also, you
are of course correct that I'm being insulting. I'm just doing it
politely. The difference between what you wrote and what I wrote is
that you had to think for a bit before you realized the insult,
whereas a number of people spotted that you were being insulting
(which you were, even if you did not mean to be) in your original
post.

On Fri, May 17, 2013 at 5:13 PM, Sod Almighty wrote:

I see. So deliberately insulting me is fine, but using exclamation marks and
expressing surprise that anyone can use a language without generics is
unacceptable?

On Saturday, 18 May 2013 01:23:50 UTC+1, Ian Lance Taylor wrote:
No. Neither is fine. At least not if the goal is to actually
communicate ideas.

On Fri, May 17, 2013 at 4:32 PM, Sod Almighty wrote:

I think perhaps you mean "flagrantly deficient". I didn't say anything
about how it smells.

Well, if you're gonna read several layers of indirection into my words,
sure. Thing is, I mean what I say and, conversely, say what I mean. I don't
imply that people are stupid - if I think they're stupid, I say so. And I
honestly have no idea how to say exactly what I said in my original post
but "presented" in a different way that happens to prevent people
performing indirection on it and ending up insulted.

On Saturday, 18 May 2013 02:04:56 UTC+1, Kyle Lemons wrote:
On Fri, May 17, 2013 at 4:32 PM, Sod Almighty <sod.al...@gmail.com<javascript:>
Hmm. I would like to try my hand at a rewrite.

On 18/05/2013, at 10:35 AM, "Kyle Lemons" wrote:

As a bit of an aside, there is a package somewhere (a bit of searching didn't turn up the name, though I'm sure someone around will remember) that allows you to write SQL queries using chained functions in the way you describe by using interfaces. I feel like it had "pretty" or "simple" in the name, if that jogs anyone's memory

On Friday, May 17, 2013 6:04:56 PM UTC-7, Kyle Lemons wrote:

On Fri, May 17, 2013 at 4:32 PM, Sod Almighty <sod.al...@gmail.com<javascript:>
Hmm. I would like to try my hand at a rewrite. Here goes:

Hi all.

I'm trying to implement a Linq<http://msdn.microsoft.com/en-us/library/vstudio/bb397926.aspx>-alike
for Go. In the process of doing so, I've run into a few paradigms that I
haven't been able to translate clearnly into Go.

1. *Generics.* I am used to having generics at my disposal, and I
haven't been able to create an API that is able to be as simultaneously
concise and type-safe as I would like.

2. *Overloading.* One way I'd typically be able to side-step the
generics issue is with overloading.

3. *Methods on predefined types.* If I could define methods on the
predefined types, I would be able to make them implement interfaces, which
might help to create a suitable API.

I'm excited to learn a new compiled systems language, but I haven't been
using Go for very long and I would like some tips about what an idiomatic
API for a LINQ-alike would be.

As an example, I want a function which is conceptually like this:

func Ana(seed T, condition func(T) bool, next func(T) T) FEnumerable<T> {
... code ...
}

I Ideally I would be able to chain statements like
"From(something).Where(filter).Select(transformation)". I've tried a
few different approaches:

(1) Return an interface
- ... problems you ran into ...
(2) ... other attempted solution ...

Here is the latest version of my code: http://example.com/foo/linq

If anyone has any tips about how to approach this or pointers to APIs that
have done it in an idiomatic way, it would be much appreciated!

As a bit of an aside, there is a package somewhere (a bit of searching
didn't turn up the name, though I'm sure someone around will remember) that
allows you to write SQL queries using chained functions in the way you
describe by using interfaces. I feel like it had "pretty" or "simple" in
the name, if that jogs anyone's memory.

On Fri, May 17, 2013 at 8:30 PM, wrote:
What I'd like to know is what are the pitfalls of compile-time struct
mixins? i.e:

import (
"io"
"code.google.com/p/sneakygophers" `mixin:"ExampleNumber(uint64)"`
)

where the sneakygophers (made-up name) package is imported with methods on
the struct type sneakygophers.ExampleNumber aliasing to uint64 *only within
the mixin package*? Admittedly, I haven't thought through the full
implications of this, as I am still busy learning the language itself. Does
this complicate things too much? Does it make sense to have an explicit
file-local or package-local ability to augment types with methods for the
purpose of satisfying interfaces? If you have to be explicit, you make it
extremely obvious when you're abusing templates, because you have to tell
the source to instantiate the implementation each time you add one
(...which is no worse than what we have now?).

On Sat, May 18, 2013 at 7:44 AM, Ian Lance Taylor wrote:
The main thing that troubles me about this approach is that it becomes
awkward to have containers of containers. You need to somehow
specialize the container package for the base type, and then
specialize it again for the container type. It's a tempting idea but
I don't really think it's the way to go.

Ian

--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

I propose a rethinking of one of the "getting generics right" tenets --
the focus on making the compile time not just blazingly fast, but as fast
as possible, "double blazing" if that was a phrase.

The Go developers have structured the language to allow amazingly fast
compile times. They have implemented it in a way that realizes these
amazingly fast compiles. For example, the whole language and libraries bild
in a minute on my little notebook computer. Amazing!

That said, there is a point where frugal can become miserly, and I suggest
that generics should cause reevaluation of means and end on this very
point. Here is the basic a general C++ like template system (user view) but
with a magical and fast aspect made possible by Go's structure. The magic
is in the importing. We need a flag in there (invisible to the developer)
than says "Templates are used in this package or in its dependencies, and
these are what they are."

This allows the the compiler to know a priori which generic specifications
need to be instantiated and what type combinations they need to be
instantiated for.

This allows the concrete calling sequences to be known when the callers
are being compiled.

This allows the compiler to emit the instantiations just once, at its
discretion in terms of when.


In spirit, it means "compiling twice" and that's what makes it simple to
implement and explain. But the hierarchical nature of the package manifests
and their pre-order visitation by the compiler means that you actually only
have to do it once since you're building the template and instantiation
tree efficiently as part of decoding package data (so you never have to
discover a fact twice.)

How fast would this be? Same speed as now when no generics are in use.
Similar speed in parse/analyze package headers as now. Extra time to
instantiate the minimal set of templated functions, but this is 1:1 with
the time to compile the same functions is elaborated manually by the
developer, so a tie.

There would be a memory cost in keeping the "for those packages that rely
on a template, here are the pointers to definitions of when they need to
have instantiated" data structures during that package tree traversal. But
at the end of that traversal the necessary functions could be immediately
instantiated if desired and then the whole data structure deleted.
Everything else in the compile can then proceed as now (with lexical
substitution of the expanded template names happening, of course.)

Here is the frugal/miserly as fast as possible argument: if this process
adds more than a few percent to the compile time, I would be surprised. But
let's be generous and say it costs an extra 5% of the entire time for
compiles where even one generic is used. I'm saying that 1 minute and 3
seconds would not be too much of an increase over the existing
blazingly-fast one minute. This is a worthy place to spend a tiny bit of
our time savings account, yet we'll never even consider it if we keep the
initial condition of "as fast as possible." Let's weaken that to just
"amazingly, awesomely, astoundingly fast" and be willing to use a percent
or two of the peak speed to give developers peak speed in their work.

Michael
(In Amsterdam)

On Sat, May 18, 2013 at 7:44 AM, Ian Lance Taylor <ia...@golang.org<javascript:>

--
Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>

you need to [...] cast the slice of Person to a slice of
PersonSortingByAge

On 18/05/2013, at 7:04 PM, "Aram Hăvărneanu" wrote:

You can't have generic containers in Go, but that's another thing.

On Saturday, May 18, 2013, Gerard wrote:

Michael, I like your motivating posts.

I am not an expert in the subject of generics, however I don't see any
real benefit of them. Why? Because they are being misused. A nice example
is a first grade C++ chess engine, Stockfish<https://github.com/mcostalba/Stockfish>.
If you look at the header files, it's template all over. And that's because
the types, declared in types.h are enums, so in fact they are all ints. And
C++ can't handle the enums. In Go, when you want the types (derived ints),
just define an interface with a getter and that's it. So, yes there is some
boilerplate, but the code is still compact and, most of all, clear and easy
to understand.

Btw, have fun in Amsterdam. And be aware of the dog poo on the sidewalks.

Op zaterdag 18 mei 2013 09:33:02 UTC+2 schreef Michael Jones het volgende:

I propose a rethinking of one of the "getting generics right" tenets --
the focus on making the compile time not just blazingly fast, but as fast
as possible, "double blazing" if that was a phrase.

The Go developers have structured the language to allow amazingly fast
compile times. They have implemented it in a way that realizes these
amazingly fast compiles. For example, the whole language and libraries bild
in a minute on my little notebook computer. Amazing!

That said, there is a point where frugal can become miserly, and I suggest
that generics should cause reevaluation of means and end on this very
point. Here is the basic a general C++ like template system (user view) but
with a magical and fast aspect made possible by Go's structure. The magic
is in the importing. We need a flag in there (invisible to the developer)
than says "Templates are used in this package or in its dependencies, and
these are what they are."

This allows the the compiler to know a priori which generic specifications
need to be instantiated and what type combinations they need to be
instantiated for.

This allows the concrete calling sequences to be known when the callers
are being compiled.

This allows the compiler to emit the instantiations just once, at its
discretion in terms of when.


In spirit, it means "compiling twice" and that's what makes it simple to
implement and explain. But the hierarchical nature of the package manifests
and their pre-order visitation by the compiler means that you actually only
have to do it once since you're building the template and instantiation
tree efficiently as part of decoding package data (so you never have to
discover a fact twice.)

How fast would this be? Same speed as now when no generics are in use.
Similar speed in parse/analyze package headers as now. Extra time to
instantiate the minimal set of templated functions, but this is 1:1 with
the time to compile the same functions is elaborated manually by the
developer, so a tie.

There would be a memory cost in keeping the "for those packages that rely
on a template, here are the pointers to definitions of when they need to
have instantiated" data structures during that package tree traversal. But
at the end of that traversal the necessary functions could be immediately
instantiated if desired and then the whole data structure deleted.
Everything else in the compile can then proceed as now (with lexical
substitution of the expanded template names happening, of course.)

Here is the frugal/miserly as fast as possible argument: if this process
adds more than a few percent to the compile time, I would be surprised. But
let's be generous and say it costs an extra 5% of the entire time for
compiles where even one generic is used. I'm saying that 1 minute and 3
seconds would not be too much of an increase over the existing
blazingly-fast one minute. This is a worthy place to spend a tiny bit of
our time savings account, yet we'll never even consider it if we keep the
initial condition of "as fast as possible." Let's weaken that to just
"amazingly, awesomely, astoundingly fast" and be willing to use a percent
or two of the peak speed to give developers peak speed in their work.

Michael
(In Amsterdam)

On Sat, May 18, 2013 at 7:44 AM, Ian Lance Taylor <ia...@golang.org<javascript:>

--
Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>

On 2013-05-18 7:30, andrew@atoulou.se wrote:

In my opinion, it seems that with Go, magic doesn't get imported
into your source file, ever: any magic you do can be traced from
the name to the import, and the import to the source. In my mind,
the lack of generics means that the developer must explicitly
implement any code bridging the generally-implemented algorithm
with their own custom data types. This is, to me, equivalent to
declaring "I know what I'm doing and want to apply X method to Y
type. It'll work. I promise (in a compiled, typesafe way)". It also
happens to be a very verbose way of doing it, because you have to
declare a type that wraps it and supports the methods. Is there a
middle ground somewhere, or is it that automatically wrapping types
just another way of expressing something functionally equivalent to
C++ style method copying or boxing things at runtime, Java-style?

What I'd like to know is what are the pitfalls of compile-time
struct mixins? i.e:

import ( "io" "code.google.com/p/sneakygophers"
`mixin:"ExampleNumber(uint64)"` )

On May 23, 10:54 am, John Arbash Meinel wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-05-18 7:30, and...@atoulou.se wrote:








Note that there is gotgo:https://github.com/droundy/gotgo

Which predates 'go build' to back when there were Makefiles. But it
used a variant on this specific syntax to transform".got" files into
".go" files. .got files were syntactically go, but had a bit of
template definitions.

This works for macro-based templating, and defining container types.
It doesn't work quite as well when you want to nest templates (I want
a type T1<T2<T3>>>).

The code is probably a bit old, and I'm guessing it doesn't integrate
into the current build system. But it was *an* answer that people have
investigated.

John
=:->

On Saturday, May 18, 2013 12:15:49 AM UTC+1, Ian Lance Taylor wrote:

Remember that on the Internet people come from many different
backgrounds and cultures.

On Fri, May 17, 2013 at 4:37 PM, Sod Almighty wrote:

Oh, and I notice my background and culture counts for fuck-all,
incidentally. If your (or anyone else's) background and culture means that I
should take extra care not to "scare" people or use exclamation marks, why
doesn't my "background and culture" (which, despite being white and English,
I actually do have) count for a damn thing? Why aren't you telling everyone
else to take my background and culture into account, and not read shit into
my words that I didn't put there?

On 18 May 2013 02:13, Ian Lance Taylor wrote:
Because you are the newcomer to an existing forum, and as such you are
expected to adopt the prevailing norms of communication. You can work
to change those norms--but not until you have participated for a
while.
"Stupid diplomatic language" is an interesting choice of phrase. The
language of diplomacy was evolved, over time, specifically so that
nations with radical disagreements, and touchy points of pride, would
be able to communicate about important issues without getting into
fights. It's awkward and tedious, but it's not stupid. It's actually
pretty important.

Ian

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On Fri, May 17, 2013 at 7:51 PM, Sod Almighty wrote:
I get that. However, from my point of view, the content is 99% of the
message. (...) While I'm aware that the majority of people in this world
react badly to how I say things, I honestly can't do anything about it.

On Saturday, May 18, 2013 12:18:47 AM UTC+1, Gustavo Niemeyer wrote:
Have you tried Rust? It's a brilliant language.

On 05/17/2013 06:51 PM, Sod Almighty wrote:
well, in my native
language, incredulity at the limitations of a system does not equal an
insult to the people using it. I call my native language "English".
Apparently it's not the same as what everyone else is using, however.

On Friday, May 17, 2013 10:55:25 PM UTC+2, Sod Almighty wrote:

If nobody ever complained about the shortcomings of anything, nothing
would ever get done.

On Friday, May 17, 2013 10:23:25 PM UTC+1, tomwilde wrote:
Dude you're like the 3000th person to bring this up. There have been like
100 lengthy discussions about this topic. Answer has always been the same.
There's a reason why this is mentioned in the FAQ.

On Friday, May 17, 2013 11:31:53 PM UTC+2, Sod Almighty wrote:
In other words, "I'm sick of telling people there's no demand for it"?

If 3000 people want a thing, perhaps someone should give it to them. What
you're essentially saying is, three thousand people agree with me. What's
your point, exactly?

On Friday, May 17, 2013 10:35:52 PM UTC+1, tomwilde wrote:
I'm saying that 3000 people wrote before they read, did before they
thought and failed before they started.

They came from other languages, read about Go, realized the "lack" of
generics, immediately posted to the list. Left in less than an hour.

On Friday, May 17, 2013 11:38:13 PM UTC+2, Sod Almighty wrote:


I'm not surprised. They were probably called trolls. They probably figured
that a language without generics was a poorly designed language. They were
probably put off by the "no can't do" attitude.

On Friday, May 17, 2013 10:41:55 PM UTC+1, tomwilde wrote:
If you read before you wrote you would have noticed that Aaron France
quoted Ian Lance Tailor as a troll. Not you.

On Fri, May 17, 2013 at 2:38 PM, Sod Almighty wrote:

I'm not surprised. They were probably called trolls. They probably figured
that a language without generics was a poorly designed language. They were
probably put off by the "no can't do" attitude.

I'm picking this as a somewhat arbitrary point of insertion.

On Fri, May 17, 2013 at 2:54 PM, Tad Glines wrote:
As I see it there is a third way. One that has been taken before.
Create a wrapper/preprocessor language, ala Groovy, coffescript, etc...
Then the developer could choose which tradeoff they want to make (compile
speed, executabel size, and runtime speed) and then choose
the appropriate wrapper language.