Light Table funding successful, including Python support (over $300k raised)
kickstarter.com
kickstarter.com
I'm really hoping along with 7,316 other people that you can pull it off. Good luck!
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.
If my money gets abused for turning this into a lifestyle-business (employees? buy IP? WTF?) then I'll demand a refund.
He's building a freakin' text-editor, not a Mars-rocket.
An entry level engineer here is easily making 75k plus. Somebody mid level is probably looking at a median income around 125k. That doesn't mean you need that much to live, but as a supporter I don't expect him to live on ramen in the tenderloin.
I want skilled and talented engineers to build OSS products like this. I don't mind paying for that. If all goes well i'll use his product to support my career and make a lot of money. There's enough to go around to properly compensate him for his experience, labor, and vision.
Just my $0.02
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.
The tooling around dynamic languages is almost laughably primitive and limited in comparison.
Dynamic languages aren't conductive to re-factoring, and static languages are.
http://news.ycombinator.com/item?id=4057593
I don't see how it is a question of where to put the brains.
How come they invented it, then?
http://st-www.cs.illinois.edu/users/brant/Refactory/Refactor...
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.
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.
Somethings just can't be done.
class Foo:
def foo():
pass
def bar(f):
f.foo
Joking aside, your example brought the nature of the issue to life; thanks.
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.
The only gotcha is where you're eval'ing a string, but that's going to be nasty however you cut it.
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.
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.
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.
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.
"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.
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.
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.
Just because it's highly extensible doesn't mean that beating the other language's VM into doing what's needed isn't going to require a bunch of effort.
Do a search for "Pluggable Backend Infrastructure for ClojureScript, and Development of a Lua backend" and you should turn up a Google Summer of Code 2012 project which seeks to broaden the scope of the ClojureScript compiler. If that project is successful, and if LightTable supports ClojureScript, the IDE's reach may be greatly expanded in the relatively near term.
$484K =~ $316K from KS + $18K from YC + $150K from Start Fund?
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-developer...
Why are you so surprised that there'd be support/choices for Python?
All that said, I contributed fairly early on, and I wish that they would concentrate on just Clojure. The reason for my preference is that the LT devs are going to be exploring new ways to code and experimenting with just one language seems sufficient.
1. C - Not really the target audience of a tool like this.
2. Java - See above, plus plenty of competition.
3. C++ - See C.
4. Objective-C - See C, also arguably a bit of a niche (iOS).
5. C# - See Java, VirtualStudio dominates.
6. PHP - Yeah, right.
7. (Visual) Basic - Who are you kidding?
8. Python - Oh, right.
9. Perl - Only ranks high because of sys admins.
10. JavaScript - Already covered.
11. Ruby - Like Python, see below.
Basically your question seems to boil down to either of these:
1. Why was Python picked over Java/C#?
2. Why was Python picked over Ruby?
As for #1: the answer should seem obvious if you consider the category the three languages (JS, Clojure and Python) share. Plus, the market is very different and the competition is very strong and established.
As for Ruby: It's probably personal preference. There really isn't any objective reason to pick Python over Ruby or vice versa. The two are more similar than either of them would like to admit and they are perfectly interchangeable in most situations.