6 ms·

On concepts and realities

168 points by ibdknox 15y ago

daniel02216 15y ago
> 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 http://root.cern.ch/drupal/content/what-cling
DanBC 15y ago
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?
- waxjar 15y ago
  A simple browser extension like Readability or Instapaper can extract the article and display it in a readable manner. That way you don't have to miss out on potentially interesting articles if you don't like the design or are distracted by certain elements on a website. It works pretty well :)
- msutherl 15y ago
  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 15y ago
    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.
    - deleted 15y ago
      [deleted]
- Rayne 15y ago
  I don't think so. Temporary blindness or inability to read English notwithstanding, the article is perfectly readable.
- lucastx 15y ago
  At least in Firefox, you can disable stylesheets at "View -> Page Style -> No Style".
  - derleth 15y ago
    So why would anyone use stylesheets less readable than the baseline provided by not having stylesheets?
gramsey 15y ago
> "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 15y ago
  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.
radicalbyte 15y ago
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.
- ibdknox 15y ago
  I agree. My first proof point is getting to where I'm moderately productive writing Light Table in itself. That should provide the bare necessities and ensure that I'm focusing on the right things instead of features that happen to seem cool :)
- nickik 15y ago
  What ur problem with version controll? Its not really about files anymore, git does not care about files.
- politician 15y ago
  Could you fix files if you mounted the IDE atop a git repo; directly storing chunks as git objects?
- tikhonj 15y ago
  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.
errnoh 15y ago
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.
deleted 15y ago
[deleted]
nhangen 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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 15y ago
        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.
pfanner 15y ago
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 15y ago
  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.
kenkam 15y ago
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.
deleted 15y ago
[deleted]
nwienert 15y ago
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.
- phyzome 15y ago
  I expect that it will be easily extensible, so it may not be Chris's team that writes the Ruby support.
- carterschonwald 15y ago
  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 15y ago
    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 15y ago
      Ok, sounds like a sensible approach that prevents the editor from crashing! :-)
awolf 15y ago
This site is seriously hard to read. There is not enough contrast between the text and its background.
JesseAldridge 15y ago
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.
there 15y ago
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.
- ibdknox 15y ago
  I'm curious myself... I didn't do it.
- Cushman 15y ago
  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.
jswanson 15y ago
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
kamaal 15y ago
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.

168 points by ibdknox 15y ago

> 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 http://root.cern.ch/drupal/content/what-cling

DanBC 15y ago

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?

waxjar 15y ago
A simple browser extension like Readability or Instapaper can extract the article and display it in a readable manner. That way you don't have to miss out on potentially interesting articles if you don't like the design or are distracted by certain elements on a website. It works pretty well :)
msutherl 15y ago
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 15y ago
  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.
  - deleted 15y ago
    [deleted]
Rayne 15y ago
I don't think so. Temporary blindness or inability to read English notwithstanding, the article is perfectly readable.
lucastx 15y ago
At least in Firefox, you can disable stylesheets at "View -> Page Style -> No Style".
- derleth 15y ago
  So why would anyone use stylesheets less readable than the baseline provided by not having stylesheets?

gramsey 15y ago

> "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 15y ago
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.

radicalbyte 15y ago

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.

ibdknox 15y ago
I agree. My first proof point is getting to where I'm moderately productive writing Light Table in itself. That should provide the bare necessities and ensure that I'm focusing on the right things instead of features that happen to seem cool :)
nickik 15y ago
What ur problem with version controll? Its not really about files anymore, git does not care about files.
politician 15y ago
Could you fix files if you mounted the IDE atop a git repo; directly storing chunks as git objects?
tikhonj 15y ago
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.

errnoh 15y ago

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.

deleted 15y ago

[deleted]

nhangen 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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.

pfanner 15y ago

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 15y ago
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.

kenkam 15y ago

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.

deleted 15y ago

[deleted]

nwienert 15y ago

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.

phyzome 15y ago
I expect that it will be easily extensible, so it may not be Chris's team that writes the Ruby support.
carterschonwald 15y ago
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 15y ago
  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 15y ago
    Ok, sounds like a sensible approach that prevents the editor from crashing! :-)

awolf 15y ago

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

JesseAldridge 15y ago

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.

there 15y ago

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.

ibdknox 15y ago
I'm curious myself... I didn't do it.
Cushman 15y ago
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.

jswanson 15y ago

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

kamaal 15y ago

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.