Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Light Table - a new IDE concept

chris-granger.com

Post reply on HN
Print view View original

141–150 of 315 posts

Re: Light Table - a new IDE concept

#141

Post by [deleted] »

Dove wrote: post #87
gruseom wrote: post #67

Earlier quoted context omitted.

Editing complex functions in a spreadsheet is an absolute nightmare Can you expand on why? Also, if you can imagine a spreadsheet that actually did a good job of this, what would it look like?

I can think of a few reasons, though they may not be the ones he has in mind. There's the fact that you're dealing with cell references rather than variable names, so all of your expressions look like ($K4 - $S$1) rather than (principal - payment). There's the fact that the IDE you're working in is trash -- rather than a text file with carefully indented parenthetical statements, it's a single line text field. Sort o…

[deleted]

Re: Light Table - a new IDE concept

#142

Post by agentultra »

It looks a lot like what I already do with Emacs.

Is Light Table also programmable in the language it's written in? I find extensibility and compose-ability far more important in an editor than any single feature alone.

Cool demo. I like the idea of alternate real-time visualizations of my code; especially in large and unfamiliar systems.

Re: Light Table - a new IDE concept

#143

Post by katabatic »

kijin wrote: post #101
SoftwareMaven wrote: post #88

Earlier quoted context omitted.

Why is that a bad thing (aside from the "I had to walk uphill both ways through the snow" aspect)? A significant portion of this generation doesn't understand CPUs and buses. They wouldn't have been able to write anything remotely complex 20 years ago). That doesn't seem to be hindering things much, though. There are still system programmers out there who dive into it, but our abstractions have gotten good enough tha…

CPUs and buses have been abstracted away pretty successfully by now, especially if you use a high-level language. But I can't imagine that the same will happen to file systems, at least not in the next 10 years. Too many of our critical tools, like all version control systems, depend on knowing where in the file system hierarchy your stuff is stored. Even if your IDE hides that from you, you'll need to know where to…

Really? iOS has very effectively abstracted away the filesystem at a consumer level. I don't see it as much of a jump to see that occurring at the programming level, at least for application-level coding.

Obviously, there will always be a need for a class of programmers who are intimately familiar with the lowest levels, but that set of programmers will always be vastly smaller than the numbers of those who code line-of-business applications, etc...

Re: Light Table - a new IDE concept

#144

Post by nikcub »

Dove wrote: post #87
gruseom wrote: post #67

Earlier quoted context omitted.

Editing complex functions in a spreadsheet is an absolute nightmare Can you expand on why? Also, if you can imagine a spreadsheet that actually did a good job of this, what would it look like?

I can think of a few reasons, though they may not be the ones he has in mind. There's the fact that you're dealing with cell references rather than variable names, so all of your expressions look like ($K4 - $S$1) rather than (principal - payment). There's the fact that the IDE you're working in is trash -- rather than a text file with carefully indented parenthetical statements, it's a single line text field. Sort o…

Excel + VBA solves a lot of that. The spreadsheet part just becomes a view.

Somebody should really build a web app version of that, there are millions of custom Excel+VBA spreadsheets spread throughout businesses across the world.

The only way they will migrate online is either through custom web apps (I used to do a lot of those) or with a generic solution which doesn't exist yet.

Re: Light Table - a new IDE concept

#145

Post by waqf »

marbletiles wrote: post #64

Am I the only one who wants to see multiple, proportional fonts in editors? Sure, I want to keep the methods themselves in monospaced font, but can't I have the method declaration in a larger size, and comments in a proportional serif? There is a wealth of design experience out there in communicating things better and more quickly with typography, so why do we not take advantage of that in our IDEs?

In most cases there's little reason to have the code in monospaced font either. People really just need their blocks (and their continuation lines) to be properly left-aligned, and that works fine, because even in proportional fonts, a tab at the beginning of the line is always the same width.

Just don't mix spaces and tabs.

Sometimes you want columns of figures to be aligned throughout, but fortunately most fonts respect the rule that all digits should be the same width (for exactly this reason).

My emacs is set for Dejavu Sans semicondensed bold at 6pt ... I find that for code, bold or demibold works a lot better than regular weight.

Re: Light Table - a new IDE concept

#146

Post by haldean »

puredanger wrote: post #130
ibdknox wrote: post #54

Earlier quoted context omitted.

There are several options here: - show multiple iterations in place - show a single iteration with a forward and back - show multiple blocks for some reasonable n iterations - ... I definitely don't think that's going to be an issue longer term and I think there are lots of potential avenues to play around with :)

You could just sample and show an example - that's good enough for many uses.

I like the previous/next idea -- for me, it's often much easier to understand what a chunk of code does when you can see its behavior on multiple inputs.

Re: Light Table - a new IDE concept

#147

Post by timdorr »

splatcollision wrote: post #133
timdorr wrote: post #89

Earlier quoted context omitted.

Kickstarter is for products, YC is for businesses. (More or less, I'm not saying it's black and white)

Ah, but business should be product-based...

That's certainly true, but the two aren't mutually exclusive. Kickstarter will get you the funds to go out and build a cool product, but it won't tell you how to generate a model that's sustainable, teach you how to go to market, or even tell you if there's an available market at all.

Re: Light Table - a new IDE concept

#148

Post by gruseom »

drostie wrote: post #117
gruseom wrote: post #67

Earlier quoted context omitted.

Editing complex functions in a spreadsheet is an absolute nightmare Can you expand on why? Also, if you can imagine a spreadsheet that actually did a good job of this, what would it look like?

Spreadsheets would be nicer if they had a coherent dataflow model. Some spreadsheet programs do this automatically, but it could be a great place for a visual programming language too. One ugly pattern that I'm often doing is to set a column with values by the function "A3=A2" and dragging that down. This gives a column of constant values which are tweakable by tweaking just the first element. That's what a scalar va…

Spreadsheets would be nicer if they had a coherent dataflow model.

What do you mean by "coherent dataflow model"? (I'm working on these problems - hence all the questions.)

This gives a column of constant values which are tweakable by tweaking just the first element. That's what a scalar variable looks like in a spreadsheet.

Why not just put the value in a cell and reference that cell absolutely?

With some visual tinkering you might even have a sort of "iframe" [...] but it should float

It seems that the general solution here would be (a) make it much easier to decompose a problem across multiple sheets (in your example, scalars and reductions could go in a different sheet), and (b) allowing sheets to "float" if you want them to, rather than always being in a different tab that you're forced to switch to. Does that make sense?

balance[i] = change[i] + balance[i - 1]

It's interesting that you single out this kind of recurrent calculation, where a later value of a column depends on an earlier value. It doesn't get mentioned very often. But it's fundamental to what spreadsheets do computationally and is the reason why parallelizing them is a lot harder than at first appears.

Re: Light Table - a new IDE concept

#149

Post by Gmo »

pragmatic wrote: post #69

"...but there's no reason this couldn't be done for any language with a dynamic runtime." With your (ibdknox) background, could this work for c#/f#? I like Visual Studio, but I feel more and more it gets in my way when I'm debugging/navigating code. There is too much "chrome"/widgets/toolbars and hundreds of specialized windows, each with their own chrome that eat up precious space on my 27" monitor. When I use it on…

I agree, working a lot with VS (and previously with Eclipse, which has the same kind of problem), on a big screen it's fine, but as soon as I have to only use my laptop screen, I cry ...

I would also love to have an editor of this kind for compiled languages ... What really sold me is seeing the flow of the data in the end of the video :)

Re: Light Table - a new IDE concept

#150

Post by waqf »

waqf wrote: post #145
marbletiles wrote: post #64

Am I the only one who wants to see multiple, proportional fonts in editors? Sure, I want to keep the methods themselves in monospaced font, but can't I have the method declaration in a larger size, and comments in a proportional serif? There is a wealth of design experience out there in communicating things better and more quickly with typography, so why do we not take advantage of that in our IDEs?

In most cases there's little reason to have the code in monospaced font either. People really just need their blocks (and their continuation lines) to be properly left-aligned, and that works fine, because even in proportional fonts, a tab at the beginning of the line is always the same width. Just don't mix spaces and tabs. Sometimes you want columns of figures to be aligned throughout, but fortunately most fonts re…

Disclaimer: although I really do code in proportional fonts, using emacs is only a 90% solution. It's harder to navigate code when hitting the up/down keys causes your cursor to jump left and right because emacs' proportional-font implementation is just a thin skin over a fixed-width world. I'm still looking for a next-generation IDE which will free me from this kind of issue.
Post reply on HN