6 ms·

Light Table funding successful, including Python support (over $300k raised)

137 points by sthlm 14y ago

bryze 14y ago
I have my own ideas about how to do this, and I'm glad someone is moving in this direction, but I must ask, is this a stepping stone in a grander vision? Enemies of software development today are: 1. Code Comprehension: Can new people quickly understand a complex code base enough to implement significant features. 2. Fault Diagnosis: When is the last time you spent less than 50% of a project's time on debugging? 3. Code Transformation: Have you ever actually tried to factor a mega-function into separate functions? How about creating a set of concrete classes when you realize that your hierarchy abstraction breaks down under new requirements. Now do all that without introducing new bugs. These are the hard problems, and it excites me that people are thinking about how to solve them. This tool will not solve all those problems, and maybe one tool shouldn't, but nevertheless I hope people will start thinking about the entire development process and how to improve all the tools of our industry.
- cageface 14y ago
  Java + a good modern IDE like IntelliJ are far from the last word on all these questions, of course, but they're much better than you might guess if you have't worked in that world for a while. I was astonished at how powerful the combination of a simple, statically typed language and a good IDE can be. You can almost completely stop thinking of code as a bunch of text and start thinking about it as an organically evolving structure. The tooling around dynamic languages is almost laughably primitive and limited in comparison.
  - gnaritas 14y ago
    > The tooling around dynamic languages is almost laughably primitive and limited in comparison. Around most dynamic languages, there are exceptions like Smalltalk which has excellent tooling including the automated refactoring and the best development environment around. Let's not forget, tools such as automated refactoring and xUnit type test tools originated in Smalltalk.
    - ConstantineXVI 14y ago
      Also, Eclipse can trace it's roots directly to VisualAge, IBM's Smalltalk based IDE platform (Eclipse began as a rewrite of VisualAge in Java).
  - theootz 14y ago
    I always loved the amount of power in java IDEs (Eclipse, for me) for refactoring code...made things so much easier.
    - 3pt14159 14y ago
      Where do you put the brains on though? In the IDE/programmer or in the language?
      - irahul 14y ago
        > Where do you put the brains on though? In the IDE/programmer or in the language? Dynamic languages aren't conductive to re-factoring, and static languages are. http://news.ycombinator.com/item?id=4057593 http://news.ycombinator.com/item?id=4057593 I don't see how it is a question of where to put the brains.
        gruseom 14y ago
        Dynamic languages aren't conductive to re-factoring How come they invented it, then? http://st-www.cs.illinois.edu/users/brant/Refactory/Refactorings.html http://st-www.cs.illinois.edu/users/brant/Refactory/Refactor...
        irahul 14y ago
        Let me rephrase. Dynamic languages aren't conductive to a subset of re-factoring - the cases which involve renaming identifiers or changing types throughout the project.
        gruseom 14y ago
        They invented those too. Indeed they're listed at the link I provided. It seems strange to argue that what gave rise to a thing isn't "conducive" to it. Actually, it's more than strange, it's a contradiction in terms: http://dictionary.reference.com/browse/conducive http://dictionary.reference.com/browse/conducive.
  - irahul 14y ago
    > The tooling around dynamic languages is almost laughably primitive and limited in comparison. Somethings just can't be done. class Foo: def foo(): pass def bar(f): f.foo If you re-factor Foo.foo to Foo.renamed, there is no way to know if the call in bar should be re-named as well.
    - adolph 14y ago
      Clippy could ask at least, right? Joking aside, your example brought the nature of the issue to life; thanks.
    - regularfry 14y ago
      Sure there is. You just need code tracing and full test coverage. You can't do it from the source alone, sure, but that doesn't mean it can't be done.
      - irahul 14y ago
        > Sure there is. You just need code tracing and full test coverage. You can't do it from the source alone, sure, but that doesn't mean it can't be done. The analog would be driving to New York from Bangalore. Sure it can be done if I arrange a car; have money for the fuel, food and stay; have all the papers etc etc. But that doesn't mean it is in any way comparable to flying to New York while watching a movie and sipping wine. Renaming a method in the public interface is always a pain - your test coverage and code tracing can numb down it a bit, but it's going to be there. Some of it is because public interfaces are a constant for all practical intent and purpose; most of it is because of the case I listed above.
        regularfry 14y ago
        I think I might not have made myself clear - given an execution trace of a test suite with full coverage (or just something which exercises every code path - it doesn't have to be a test suite, but you've already got one of those so you might as well use it, right?), you could build a tool to make a rename refactoring fully automatic in a dynamic language. At the point of use, it would be identical to a static language rename, it would just work in a different way. It's a fairly obvious idea, so I presume this has been done in the past, but I don't know of any examples offhand. The only gotcha is where you're eval'ing a string, but that's going to be nasty however you cut it.
  - facorreia 14y ago
    I have the same feeling working with C# and Visual Studio with ReSharper. It's impressive how easily I can navigate the code base, refactor with confidence and learn APIs as I go.
    - stcredzero 14y ago
      The developer of Smalltalk Agents called it while C# and dotnet still were new. Smalltalk lost as a language, but as set of expectations for dev environments, has been winning. LightTable looks to complete this.
- twelvechairs 14y ago
  I'm with you on the 'I'm glad someone is moving in this direction' vein, but to me the "Enemies of software development today" are much broader than you suggest. I am pretty strongly of the view that the fundamental line between 'developer' and 'user' (aka. 'programming' and 'program') needs to be broken down.
  - mwsherman 14y ago
    This sounds nice in theory but I don’t think it’s an interesting goal. I’ll go further: it’s been the goal all along but doesn’t have traction. SQL was designed as a “business” language, for end users (what we now call information workers). Didn’t happen. There have been many promises of “visual” languages, just drag and drop components and you have an app. The issue is not tools, but the fact that programming is a logical business. The best programmers are logicians – they have a robust mental model of a problem to be solved. The coding (and the tools) help, but they ain’t the thing. Basically, being capable of manipulating Illustrator does not an artist make. In fact, programming has been moving in the other direction: more people I know use Ruby on a command line than Visual Studio’s design surfaces. The frontier is in end-user UI. Progress is when we allow users to be more ambiguous, less logical, and still give them what they want.
    - twelvechairs 14y ago
      Thanks for the response. After your first sentence I was looking for something to disagree with. But actually I agree with you on pretty much every point you make here - I am just slightly unsure how this disagrees with what I said previously. My guess (from your second last para. especially) is that you think I am advocating more 'dumbed down' high-level visual languages/ides/etc. which I really don't mean to - at least not like the ones of the past. To me these tend to really fail at what I want because they tend to: (1) have a very limited scope of functions (2) have pretty fixed interfaces which simplify certain tasks, but also make others much more complex than a simple command line or similar (3) not make it easy for you to transition to other environments [to learn something with different or lower-level functions]. To me, many of the subtleties of implementation (such as the points I just made above) often actually matter a lot more than the big words (like 'visual programming', 'IDE', 'UI' etc.) that are bandied about far more often. I guess its my fault for trying to be terse. I think it is very difficult to discuss these things in message-board format because different words mean very different things to different people. In the end I think we are probably looking at the same goal from different directions.
- vineet 14y ago
  I completely agree with the above. I spent my PhD building prototypes and tools for the above. Check out what we have done at: http://www.architexa.com http://www.architexa.com. Would love to hear your thoughts (see my profile for my email address). And feel free to get in touch for a free license of our software.
voxx 14y ago
I can't believe they (devs) chose python over ruby or java or scala or ANYTHING but python.
- theootz 14y ago
  And what's wrong with Python?
  - deleted 14y ago
    [deleted]
  - sgrove 14y ago
    Python's a great fit, certainly a more straight-forward one than java/scala. Presumably python/ruby would be equally interesting additions to Light Table
  - peterhajas 14y ago
    I'm guessing the commenter has a thing against Python for some reason.
- david_shaw 14y ago
  They actually opened it up to additional funding specifically to include Python. That money was raised based on community support (including financial support), so now they're including it. Why are you so surprised that there'd be support/choices for Python?
- achompas 14y ago
  Fortunately Light Table will have support for packaging, so users can add any language they want.
- Tuna-Fish 14y ago
  Scala and Java are reasonably well served by traditional IDEs. Dynamic languages (such as ruby and python) are not, and based on the presentations, that's the market he is trying to serve. As for the choice between Ruby and Python, they are sufficiently similar that most of the work done to make one work will help with the other, and the choice mostly is which one he wants to support first. Python has a bigger community.
ibdknox 14y ago
Thanks to everyone: http://www.chris-granger.com/2012/06/01/45-days-later/ http://www.chris-granger.com/2012/06/01/45-days-later/
- guelo 14y ago
  Congrats on the funding! I'm sure you have excellent advisers and business plans at this point but I'm still going to be presumptuous and offer my advice: you need to be really frugal. $300k is not huge runway and before you know it will be gone. You need to keep any and all overhead low and plow as much as possible into development. Your project is ambitious and expectations are high, you need leeway for false starts, do-overs, pivots, impatient users, fickle press, etc. I'm really hoping along with 7,316 other people that you can pull it off. Good luck!
  - onedev 14y ago
    Please listen to this guy.
  - moe 14y ago
    $300k is not huge runway I like lighttable (and donated, too), but this is getting ridiculous. $300k is one hell of a runway. Neither Vim nor Emacs had any kind of runway. Hardly any bootstrapped startup has that kind of money lying around. The onus is now on him to deliver something worthwhile. $300k can comfortably carry an individual for 4+ years, no frugality needed at all. I sure hope we'll see results sooner than that.
    - bangbang 14y ago
      Naw, your parent is right. When you have a legit business running, there's lots of expenses that come along with it. State, local, county taxes, accountant to keep the rest out of trouble. If you have an employee, there's yet more taxes, business insurance, liability insurance the expenses really go on and on. That 300K is more like 200k, and if he wants to have help (mediocre help), it's more like 130K (50K+employment taxes, benefits?) that is unless he wants 2 helpers then it's more like 85k and that's if he doesn't pay himself... It really isn't much money. Heaven forbid he needs to buy licensing for some IP along the way.
fernandezpablo 14y ago
They say: "Ultimately the goal of the platform is to be a highly extensible work surface" Still they needed 100k for adding Python support? I guess ruby/scala support is not happening anytime soon.
- scottjad 14y ago
  I think you're thinking about this wrong. Python support appears to be an incentive/carrot to help raise more money in general, not just for that feature. So Chris probably thought "it would be nice if we could raise even more money" for all sorts of features and picked one of them (built-in Python support) to use as an incentive.
  - ezer 14y ago
    Python was a great choice as an incentive for raising more money, considering the size of the community.
- sthlm 14y ago
  I thought the whole budget was rather low compared to the total value that is to be created. Sure, 100k for 1 language sounds odd, given that 200k was enough not only for 2 languages, but also the entire framework. Still, the overall price point is more than fair. You have to take into consideration that Light Table aims to be specific; adding further languages will likely result in more efforts than merely adjusting an IDE a little bit.
  - mwhooker 14y ago
    it's not as if we were purchasing one language. It's a stretch goal, with python as the reward. The goal and the difficulty of implementation are not related.
  - fernandezpablo 14y ago
    I'm not saying 300k is a lot of money for LightTable. Sure, it sounds fair. I'm just saying they claim to be "highly extensible" and yet, support for a new language requires a development effort of 100k. It's sad since I mostly code in ruby or scala, these languages won't be supported and I don't think anyone is going to make a 100k development effort to support them.
redthrowaway 14y ago
Glad I got in when a license was $15. If there's one feature I'd like in the future, it's extensibility. Let dev communities write their own plugins for languages, so it doesn't all fall on Granger's lap.
- SoftwareMaven 14y ago
  It's not just desirable; it's absolutely required. Look at every successful dev environment and you'll see a large community of developers making it better. Those that survive in spite of this (eg Xcode) do so because something else forces their continued existence (such as being the only way onto the iPhone).
deleted 14y ago
[deleted]
soapdog 14y ago
I am a backer and I just want to say that I am anxious to see it running... =)
DivisibleByZero 14y ago
It's really exciting to see a great development tool. While I love vim and will passionately fight for it's place as the best 'text editor'. I readily recognize it's faults as a development environment. All the other tools I've seen up to this point seem to be a text editor with plugins or additional components stacked on top. Even IDEs seem to follow this pattern and are development tools built on a text editor. It is nice to see a holistic approach to designing development environment from the ground up. To me light table looks to be the first real development environment as opposed to an improvement.
nivertech 14y ago
So the total funding will be something like: $484K =~ $316K from KS + $18K from YC + $150K from Start Fund?
- dkersten 14y ago
  -KS's cut
  - JackC 14y ago
    - Amazon's cut - prize fulfillment costs At smaller scales, there can be a huge difference between sticker price and what you actually have to work with: http://kotaku.com/5902280/what-the-hell-these-game-developers-did-with-your-kickstarter-money http://kotaku.com/5902280/what-the-hell-these-game-developer...

137 points by sthlm 14y ago

bryze 14y ago

I have my own ideas about how to do this, and I'm glad someone is moving in this direction, but I must ask, is this a stepping stone in a grander vision? Enemies of software development today are: 1. Code Comprehension: Can new people quickly understand a complex code base enough to implement significant features. 2. Fault Diagnosis: When is the last time you spent less than 50% of a project's time on debugging? 3. Code Transformation: Have you ever actually tried to factor a mega-function into separate functions? How about creating a set of concrete classes when you realize that your hierarchy abstraction breaks down under new requirements. Now do all that without introducing new bugs. These are the hard problems, and it excites me that people are thinking about how to solve them. This tool will not solve all those problems, and maybe one tool shouldn't, but nevertheless I hope people will start thinking about the entire development process and how to improve all the tools of our industry.

cageface 14y ago
Java + a good modern IDE like IntelliJ are far from the last word on all these questions, of course, but they're much better than you might guess if you have't worked in that world for a while. I was astonished at how powerful the combination of a simple, statically typed language and a good IDE can be. You can almost completely stop thinking of code as a bunch of text and start thinking about it as an organically evolving structure. The tooling around dynamic languages is almost laughably primitive and limited in comparison.
- gnaritas 14y ago
  > The tooling around dynamic languages is almost laughably primitive and limited in comparison. Around most dynamic languages, there are exceptions like Smalltalk which has excellent tooling including the automated refactoring and the best development environment around. Let's not forget, tools such as automated refactoring and xUnit type test tools originated in Smalltalk.
  - ConstantineXVI 14y ago
    Also, Eclipse can trace it's roots directly to VisualAge, IBM's Smalltalk based IDE platform (Eclipse began as a rewrite of VisualAge in Java).
- theootz 14y ago
  I always loved the amount of power in java IDEs (Eclipse, for me) for refactoring code...made things so much easier.
  - 3pt14159 14y ago
    Where do you put the brains on though? In the IDE/programmer or in the language?
    - irahul 14y ago
      > Where do you put the brains on though? In the IDE/programmer or in the language? Dynamic languages aren't conductive to re-factoring, and static languages are. http://news.ycombinator.com/item?id=4057593 http://news.ycombinator.com/item?id=4057593 I don't see how it is a question of where to put the brains.
      - gruseom 14y ago
        Dynamic languages aren't conductive to re-factoring How come they invented it, then? http://st-www.cs.illinois.edu/users/brant/Refactory/Refactorings.html http://st-www.cs.illinois.edu/users/brant/Refactory/Refactor...
        irahul 14y ago
        Let me rephrase. Dynamic languages aren't conductive to a subset of re-factoring - the cases which involve renaming identifiers or changing types throughout the project.
        gruseom 14y ago
        They invented those too. Indeed they're listed at the link I provided. It seems strange to argue that what gave rise to a thing isn't "conducive" to it. Actually, it's more than strange, it's a contradiction in terms: http://dictionary.reference.com/browse/conducive http://dictionary.reference.com/browse/conducive.
- irahul 14y ago
  > The tooling around dynamic languages is almost laughably primitive and limited in comparison. Somethings just can't be done. class Foo: def foo(): pass def bar(f): f.foo If you re-factor Foo.foo to Foo.renamed, there is no way to know if the call in bar should be re-named as well.
  - adolph 14y ago
    Clippy could ask at least, right? Joking aside, your example brought the nature of the issue to life; thanks.
  - regularfry 14y ago
    Sure there is. You just need code tracing and full test coverage. You can't do it from the source alone, sure, but that doesn't mean it can't be done.
    - irahul 14y ago
      > Sure there is. You just need code tracing and full test coverage. You can't do it from the source alone, sure, but that doesn't mean it can't be done. The analog would be driving to New York from Bangalore. Sure it can be done if I arrange a car; have money for the fuel, food and stay; have all the papers etc etc. But that doesn't mean it is in any way comparable to flying to New York while watching a movie and sipping wine. Renaming a method in the public interface is always a pain - your test coverage and code tracing can numb down it a bit, but it's going to be there. Some of it is because public interfaces are a constant for all practical intent and purpose; most of it is because of the case I listed above.
      - regularfry 14y ago
        I think I might not have made myself clear - given an execution trace of a test suite with full coverage (or just something which exercises every code path - it doesn't have to be a test suite, but you've already got one of those so you might as well use it, right?), you could build a tool to make a rename refactoring fully automatic in a dynamic language. At the point of use, it would be identical to a static language rename, it would just work in a different way. It's a fairly obvious idea, so I presume this has been done in the past, but I don't know of any examples offhand. The only gotcha is where you're eval'ing a string, but that's going to be nasty however you cut it.
- facorreia 14y ago
  I have the same feeling working with C# and Visual Studio with ReSharper. It's impressive how easily I can navigate the code base, refactor with confidence and learn APIs as I go.
  - stcredzero 14y ago
    The developer of Smalltalk Agents called it while C# and dotnet still were new. Smalltalk lost as a language, but as set of expectations for dev environments, has been winning. LightTable looks to complete this.
twelvechairs 14y ago
I'm with you on the 'I'm glad someone is moving in this direction' vein, but to me the "Enemies of software development today" are much broader than you suggest. I am pretty strongly of the view that the fundamental line between 'developer' and 'user' (aka. 'programming' and 'program') needs to be broken down.
- mwsherman 14y ago
  This sounds nice in theory but I don’t think it’s an interesting goal. I’ll go further: it’s been the goal all along but doesn’t have traction. SQL was designed as a “business” language, for end users (what we now call information workers). Didn’t happen. There have been many promises of “visual” languages, just drag and drop components and you have an app. The issue is not tools, but the fact that programming is a logical business. The best programmers are logicians – they have a robust mental model of a problem to be solved. The coding (and the tools) help, but they ain’t the thing. Basically, being capable of manipulating Illustrator does not an artist make. In fact, programming has been moving in the other direction: more people I know use Ruby on a command line than Visual Studio’s design surfaces. The frontier is in end-user UI. Progress is when we allow users to be more ambiguous, less logical, and still give them what they want.
  - twelvechairs 14y ago
    Thanks for the response. After your first sentence I was looking for something to disagree with. But actually I agree with you on pretty much every point you make here - I am just slightly unsure how this disagrees with what I said previously. My guess (from your second last para. especially) is that you think I am advocating more 'dumbed down' high-level visual languages/ides/etc. which I really don't mean to - at least not like the ones of the past. To me these tend to really fail at what I want because they tend to: (1) have a very limited scope of functions (2) have pretty fixed interfaces which simplify certain tasks, but also make others much more complex than a simple command line or similar (3) not make it easy for you to transition to other environments [to learn something with different or lower-level functions]. To me, many of the subtleties of implementation (such as the points I just made above) often actually matter a lot more than the big words (like 'visual programming', 'IDE', 'UI' etc.) that are bandied about far more often. I guess its my fault for trying to be terse. I think it is very difficult to discuss these things in message-board format because different words mean very different things to different people. In the end I think we are probably looking at the same goal from different directions.
vineet 14y ago
I completely agree with the above. I spent my PhD building prototypes and tools for the above. Check out what we have done at: http://www.architexa.com http://www.architexa.com. Would love to hear your thoughts (see my profile for my email address). And feel free to get in touch for a free license of our software.

voxx 14y ago

I can't believe they (devs) chose python over ruby or java or scala or ANYTHING but python.

theootz 14y ago
And what's wrong with Python?
- deleted 14y ago
  [deleted]
- sgrove 14y ago
  Python's a great fit, certainly a more straight-forward one than java/scala. Presumably python/ruby would be equally interesting additions to Light Table
- peterhajas 14y ago
  I'm guessing the commenter has a thing against Python for some reason.
david_shaw 14y ago
They actually opened it up to additional funding specifically to include Python. That money was raised based on community support (including financial support), so now they're including it. Why are you so surprised that there'd be support/choices for Python?
achompas 14y ago
Fortunately Light Table will have support for packaging, so users can add any language they want.
Tuna-Fish 14y ago
Scala and Java are reasonably well served by traditional IDEs. Dynamic languages (such as ruby and python) are not, and based on the presentations, that's the market he is trying to serve. As for the choice between Ruby and Python, they are sufficiently similar that most of the work done to make one work will help with the other, and the choice mostly is which one he wants to support first. Python has a bigger community.

ibdknox 14y ago

Thanks to everyone: http://www.chris-granger.com/2012/06/01/45-days-later/ http://www.chris-granger.com/2012/06/01/45-days-later/

guelo 14y ago
Congrats on the funding! I'm sure you have excellent advisers and business plans at this point but I'm still going to be presumptuous and offer my advice: you need to be really frugal. $300k is not huge runway and before you know it will be gone. You need to keep any and all overhead low and plow as much as possible into development. Your project is ambitious and expectations are high, you need leeway for false starts, do-overs, pivots, impatient users, fickle press, etc. I'm really hoping along with 7,316 other people that you can pull it off. Good luck!
- onedev 14y ago
  Please listen to this guy.
- moe 14y ago
  $300k is not huge runway I like lighttable (and donated, too), but this is getting ridiculous. $300k is one hell of a runway. Neither Vim nor Emacs had any kind of runway. Hardly any bootstrapped startup has that kind of money lying around. The onus is now on him to deliver something worthwhile. $300k can comfortably carry an individual for 4+ years, no frugality needed at all. I sure hope we'll see results sooner than that.
  - bangbang 14y ago
    Naw, your parent is right. When you have a legit business running, there's lots of expenses that come along with it. State, local, county taxes, accountant to keep the rest out of trouble. If you have an employee, there's yet more taxes, business insurance, liability insurance the expenses really go on and on. That 300K is more like 200k, and if he wants to have help (mediocre help), it's more like 130K (50K+employment taxes, benefits?) that is unless he wants 2 helpers then it's more like 85k and that's if he doesn't pay himself... It really isn't much money. Heaven forbid he needs to buy licensing for some IP along the way.

fernandezpablo 14y ago

They say: "Ultimately the goal of the platform is to be a highly extensible work surface" Still they needed 100k for adding Python support? I guess ruby/scala support is not happening anytime soon.

scottjad 14y ago
I think you're thinking about this wrong. Python support appears to be an incentive/carrot to help raise more money in general, not just for that feature. So Chris probably thought "it would be nice if we could raise even more money" for all sorts of features and picked one of them (built-in Python support) to use as an incentive.
- ezer 14y ago
  Python was a great choice as an incentive for raising more money, considering the size of the community.
sthlm 14y ago
I thought the whole budget was rather low compared to the total value that is to be created. Sure, 100k for 1 language sounds odd, given that 200k was enough not only for 2 languages, but also the entire framework. Still, the overall price point is more than fair. You have to take into consideration that Light Table aims to be specific; adding further languages will likely result in more efforts than merely adjusting an IDE a little bit.
- mwhooker 14y ago
  it's not as if we were purchasing one language. It's a stretch goal, with python as the reward. The goal and the difficulty of implementation are not related.
- fernandezpablo 14y ago
  I'm not saying 300k is a lot of money for LightTable. Sure, it sounds fair. I'm just saying they claim to be "highly extensible" and yet, support for a new language requires a development effort of 100k. It's sad since I mostly code in ruby or scala, these languages won't be supported and I don't think anyone is going to make a 100k development effort to support them.

redthrowaway 14y ago

Glad I got in when a license was $15. If there's one feature I'd like in the future, it's extensibility. Let dev communities write their own plugins for languages, so it doesn't all fall on Granger's lap.

SoftwareMaven 14y ago
It's not just desirable; it's absolutely required. Look at every successful dev environment and you'll see a large community of developers making it better. Those that survive in spite of this (eg Xcode) do so because something else forces their continued existence (such as being the only way onto the iPhone).

deleted 14y ago

[deleted]

soapdog 14y ago

I am a backer and I just want to say that I am anxious to see it running... =)

DivisibleByZero 14y ago

It's really exciting to see a great development tool. While I love vim and will passionately fight for it's place as the best 'text editor'. I readily recognize it's faults as a development environment. All the other tools I've seen up to this point seem to be a text editor with plugins or additional components stacked on top. Even IDEs seem to follow this pattern and are development tools built on a text editor. It is nice to see a holistic approach to designing development environment from the ground up. To me light table looks to be the first real development environment as opposed to an improvement.

nivertech 14y ago

So the total funding will be something like: $484K =~ $316K from KS + $18K from YC + $150K from Start Fund?

dkersten 14y ago
-KS's cut
- JackC 14y ago
  - Amazon's cut - prize fulfillment costs At smaller scales, there can be a huge difference between sticker price and what you actually have to work with: http://kotaku.com/5902280/what-the-hell-these-game-developers-did-with-your-kickstarter-money http://kotaku.com/5902280/what-the-hell-these-game-developer...