
On concepts and realities - ibdknox
http://www.chris-granger.com/2012/04/22/on-concepts-and-realities/
======
radicalbyte
Great. But please don't take too much notice of feedback at this stage, it's
more likely to distract* you from your core goals.

Focus on expanding the concept, listen to a _small_ group of critical people
you can trust for feedback and you'll build the tool we're all supporting you
to build :)

As an aside: to truly 'fix' files, you need to 'fix' version control. That's
out of scope for Light Table, but it's something that could be addressed by a
parallel project (if someone else fancies looking at it).

* i.e. complicating things so you can support Java/C# - few of those devs will ever use Light Table, and if the concept is a hit then you'll have Microsoft and Oracle waving big wads of cash at you to support their platforms.

~~~
tikhonj
I don't know what you have in mind for "fixing" version control, but I'm
actually working on something like that with a friend.

The basic idea is to diff and merge ASTs rather than long strings. We have
some more specific ideas about specific features and advantages, but since we
have almost no code yet I won't get into them. We should (since this is
actually for school, we _have_ to) have a working prototype several weeks from
now, so I'll talk more about it then.

We're not really fixing "version control" _per se_ ; rather, we're building a
tool that you could use in tandem with existing systems like Git. So we'll
help with diffs, interactive merges (maybe even automatic conflict
resolutions) and some other stuff but let the actual storage and versioning
stay with Git (or any other VCS).

I can't make any promises, but if we get something interesting working I'll be
sure to post it here. We actually tried to do something like this for a
hackathon once, and it sort of worked, but was really a big hack throughout.
Hopefully we'll get it right this time.

~~~
radicalbyte
That's pretty much what I had in mind: diff at language level not at text
level.

Actually, ideally you would have content-aware DIFFs. So source code has one
visualiser, images another, each binary format another.

That would make the experience much better.

------
JesseAldridge
A small piece of advice: Don't try to do everything at once. I think it would
probably be better to start with something similar to a standard text editor
with one or two bonus features and evolve that over time to your final
product. Bringing in a bunch of radical new ideas all at once seems like it
probably isn't going to work very well.

I put in $50. I think this project could be really cool if it turns into more
than just vaporware. Best of luck to you.

------
gramsey
> "Our communities are wildly different from language to language, so much so
> that idioms even contradict each other..."

> "The way Clojure developers work is very different than the way C developers
> do..."

This couldn't be more true, and makes the $200,000 investment goal a heck of
lot more reasonable. Imagine the difference between developing and testing
HTML5 games with Javascript and creating business CRUD apps with Rails. It's
very ambitious when you think about it, which is why I'm just as eager to see
how this project evolves in the next couple of months.

Light Table has a huge potential to be dynamically multilingual. Each of these
languages and platforms have vibrantly unique communities, and being able to
speak to all of them will be the "thing" that makes it worth using.

~~~
ibdknox
Dynamically multilingual is a good way of putting it. Editors can, for the
most part, serve a single set of features to many different languages, but
something like an environment has a much harder time doing that. Context
matters. Really trying to nail what works in different contexts is arguably
the greatest value that will come out of the project.

------
DanBC
Sorry, but grey on grey is unreadable.

I could install custom style sheets. But now I choose to ignore unreadable
pages.

Perhaps other people are also ignoring what you have to say, but not letting
you know?

~~~
msutherl
Grey on grey is fine for me, but the typeface is definitely too light with too
much space in the counters (how would a type-designer say this – does it make
sense to call the face too "open"?) Looks pretty though.

~~~
lbotos
Open is a good term. By chance, what OS/Browser are you on? I've been trying
to gather some feedback about the "extended" fonts available now via @font-
face and how people's OS also play a part in that.

------
awolf
This site is seriously hard to read. There is not enough contrast between the
text and its background.

------
errnoh
Instant results etc are fun things to play with, but they will not matter for
most use cases there are.

For me it's these two lines you mentioned:

1) You should never have to look for documentation

2) Files are not the best representation of code, just a convenient
serialization.

First one is easily doable and there are a lot of plugins that help you with
that.

The second is what makes this project interesting and almost made me write my
own editor the moment I first saw Light Table.

Files are indeed good way to serialize stuff, but handling each separate
section of code as independent (and at the same time, dependent on other
sections of code) could actually be a better way. At least it's something I'd
like to try.

That's also something that's doable for most languages there are.

Only thing needed are the rules that tell what parts are separate, and
additional logic that links those parts to the parts that are called from that
one to connect the whole thing as one big entity.

------
there
Why was the (originally edited) title of this submission changed just
recently? It was "Light Table - My goal" until it had 100 points, which made
it completely obvious what it was about. Now it's been changed to the author's
original title which explains absolutely nothing.

~~~
Cushman
From the guidelines:

> You can make up a new title if you want, but if you put gratuitous editorial
> spin on it, the editors may rewrite it.

What I'm saying is you're right, some editor obviously didn't read the
guideline properly. Even if "Light Table - My goal" were somehow gratuitously
editorial, the title of the blog post is a horrible choice to replace it.

------
nwienert
Love the idea but I think a big way to get a ton more backers will be to set
better levels for additional languages.

If you think about it $100,000 for python is fairly steep. Not unreasonable,
but take me for example. I develop primarily in ruby. If you add a ruby tier,
I will back the project. But I think you should make add language tiers and
make them a bit easier to reach.

If you do the foundation properly, the difference between adding Python and
Ruby should be small. Perhaps if you set Python at $250k/275k and then make
ruby and other languages an extra ~$25k you will gain the support of a HUGE
ruby audience and open up other big audiences.

Here's a +1 to ruby, and to doing it at much less than $100k.

~~~
carterschonwald
Actually, I think you're vastly underestimating the amount of resources for
each Lang to work out well. The key point is semantics. As currently
presented, light table is exploiting languages whose semantics can live on a
js substrate

If anything, I think they're optimistically underestimating the engineering
work for addin js backends for other languages (assuming that's how they plan
to have es languages integrated in.) :-)

~~~
ibdknox
The backends can be written in any language that has support for TCP and JSON.
:) Forcing people to write parsers/analyzers/etc in a language other than the
host is bound for failure in the long run.

That, however, is a subject for a later post.

~~~
carterschonwald
Ok, sounds like a sensible approach that prevents the editor from crashing!
:-)

------
nhangen
Don't worry about the haters, just keep working.

Having just gone through 9 months of rapid iteration on a product, I've
learned so much, both about building good products and about accepting (or
not) feedback.

Can't wait to see what Light Table brings to the...um...table.

~~~
evoxed
Haters, no. Critics, yes. Anyone who asks an interesting question or poses an
interesting problem shouldn't be ignored completely as long as it seems
relevant to what the creator is trying to do. Judging by the timeliness of
this post however it seems like he's doing a fine job of that.

~~~
nhangen
Why shouldn't they be ignored?

It's easy to be a critic, much more difficult to put your money where your
mouth is.

~~~
evoxed
Because when they make a persuasive argument, it forces you to work harder. To
confront the issues that other people are bringing up. If you don't want that
then you can make software just for yourself. Otherwise it's best to keep an
open ear, even if the voices do nothing to change your direction.

Criticism is no science, and sure they might not be making the same thing as
you but that doesn't mean they don't have anything valuable to say about it.
You could be a brilliant programmer but absolutely no imagination when it
comes to UX, in which case a little user criticism would go a long way and may
even bleed a little into the program architecture.

~~~
nhangen
I'm not arguing that criticism isn't valuable, I'm just arguing that it isn't
valuable when you are still in the early stages of building your idea. Build
it based on what you think it should be, see if people use it, and then accept
feedback.

The people criticizing you, especially this early, are obviously not your
customer.

------
daniel02216
> while it may seem that live evaluating a compiled language like C is far
> off, I believe that given the motivation someone will find a way

I wonder how close Cling[1] is to this ideal.

[1] <http://root.cern.ch/drupal/content/what-cling>

------
kenkam
Great positive response from the OP -- I saw the critique on the idea at the
start of today and already he has made a reply that gracefully deflects most
of the criticisms raised about the idea.

Most of us are probably aware by now that some of the features that the OP is
offering has already been done. It was pointed out that Eclipse supported docs
everywhere, for example. I agree that these are _principles_ that have a much
higher purpose than promising some neat features: they will guide and define
the development of this product.

I, almost many others, find what the OP is doing very intriguing and I am
eagerly watching how Light Table will develop into a product that perhaps we
can use one day.

------
jswanson
This post convinced me to contribute to the project.

I thought it was a great idea at first, but didn't contribute because of the
odd kickstarter levels and my own faulty perception that the project was to
create a fleshed out version of the initial demo.

Clearly stating that the priority is on your ideals was a great idea:

    
    
      - You should never have to look for documentation
      - Files are not the best representation of code, just a convenient serialization.
      - Editors can be anywhere and show you anything - not just text.
      - Trying is encouraged - changes produce instantaneous results
      - We can shine some light on related bits of code

------
pfanner
I like the idea, I think it's a right step into the future of coding. Beta
Access @ $15 Pledge would be nice though, since ppl would certainly donate
more money if they saw how cool the IDE is.

~~~
phyzome
I assume "beta access" means you'll be providing some feedback as well, which
can't apply to the lowest donation level. And I can't believe there wouldn't
be screenshots and videos as the IDE develops.

------
kamaal
Its too early in the day to get into these many details. The primary focus
must now be

    
    
        a. Set of goals.
        b. Fastest way to get to the set of goals.
        c. Building a community and getting them to contribute.
    

Anything else and we would be prematurely optimizing. And falling through a
unproductive rabit hole.

The primary focus at this time must be to worry about a basic usable product
with a extensible mechanism and growing a community. The faster you get
something out, the more awesome it will be. After this kind of a built up, not
having a quick release or a bad release will disappoint a lot of people.

Will be nice to see something in the next 6 months.

