×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Light Table: A New Spin on the IDE

Unknown Lamer posted about 2 years ago | from the zmacs-did-it-before-you-were-born dept.

Programming 137

New submitter omar.sahal writes "Bret Victor demoed the idea of instant feedback on your code. ... Allowing the programmer to instantly see what his program is doing. Chris Granger has turned this novel idea into Light Table — a new IDE designed to make use of Victor's insights." The screenshots make this look like it could be genuinely useful — like a much fancier and more functional combination of features from SLIME and Speedbar. There's a Google group for those wanting to track development. There's no code yet, but source is promised: "I can guarantee you that Light Table will be built on top of the technologies that are freely available to us today. As such, I believe it only fair that the core of Light Table be open sourced once it is launched, while some of the plugins may remained closed source."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

137 comments

What's new? (0)

Anonymous Coward | about 2 years ago | (#39699565)

How is this different from something like IntelliSense, the consoles of many scripting interpreters or simply splitting up code into various panes? This looks like a unification of ideas in a nifty wrapper rather then something revolutionary or deeply insightful.

Re:What's new? (5, Insightful)

19thNervousBreakdown (768619) | about 2 years ago | (#39699879)

What exactly is bad about finally packing up all those new ideas? I'd rather not use 9 different IDEs for the 1 cool thing each does, and besides, once you get a bunch of things together, it's often more than the sum of its parts.

Re:What's new? (1)

Twinbee (767046) | about 2 years ago | (#39700533)

get a bunch of things together, it's often more than the sum of its parts

Ah, the arch enemy of "Use the right tool tool for the right job" - my pet hate quote of all time I think.

Re:What's new? (1)

hairyfeet (841228) | about 2 years ago | (#39700583)

Because sadly here in the USA each one of those "nifty ideas" is probably copyrighted and/or patented up the ass so you'll spend more time in court than you do working on your new program?

Re:What's new? (0)

Anonymous Coward | about 2 years ago | (#39701657)

This looks like a unification of ideas in a nifty wrapper rather then something revolutionary or deeply insightful

What exactly is bad about finally packing up all those new ideas?

Since when does "this is nifty but not revolutionary" suddenly mean "this sucks ass"? And how the fuck does such a statement get a +5 Insightful?

Re:What's new? (1)

19thNervousBreakdown (768619) | about 2 years ago | (#39702615)

It doesn't have to mean "this sucks ass" to be a negative or dismissive-seeming comment. Asking "what's new?" implies that if there isn't something new, it's not worthy. Maybe that's not what the poster intended, but that's how I, and apparently at least 4 mods, read it. And posts toward the top of the page tend to be either +5 or -1 until the story drops off the front page when the fine-tuning mods don't get drowned out, that's just human nature combined with Slashdot's moderation system.

Re:What's new? (4, Informative)

omar.sahal (687649) | about 2 years ago | (#39700163)

Watch this, his lectue and demo and then tell me it's the same as we already have, and that a man charged with designing new forms of human computer interaction at Apple didn't know this. Also please respond with why he wasted our time telling us something that already comonly exsisted in the software world, as well as how the confrence organisor and who ever aproved posting missed all this. https://vimeo.com/36579366 [vimeo.com] I was happy to see my post on slashdot. It's quite heavily edited, but this has improved the post. One question for slashdot, is the reason many posts get rejected due to posters needing heavy editing and this not having been done in the past.

Re:What's new? (0)

Anonymous Coward | about 2 years ago | (#39700313)

and that a man charged with designing new forms of human computer interaction at Apple didn't know this

So apparently working on xcode was below these people. amirite?

Just give me this in emacs.... (3, Insightful)

Anonymous Coward | about 2 years ago | (#39699577)

...not some guys idea of IDE-NG

Re:Just give me this in emacs.... (0)

Anonymous Coward | about 2 years ago | (#39699633)

and what is a "The Victor"?

Re:Just give me this in emacs.... (2)

Anomalyst (742352) | about 2 years ago | (#39702133)

I'm concerned about IDE-Voyager being released. The mind boggles (or possibly yahtzees).

funding (5, Informative)

vlm (69642) | about 2 years ago | (#39699579)

Here's the funding plan:

I'm happy to announce that we submitted our Kickstarter earlier today and are simply waiting for it to be reviewed.

In other news, to save everyone the time, I'll point out that 100 people are going to post the lighttable does what smalltalk did in the 80s. As with all IT and most CS stuff, there really is nothing new under the sun, just recycling. That doesn't mean its bad, or reimplementation of a good idea is bad, just that it isn't new.

Files are not the best representation of code... (4, Insightful)

jamesbulman (103594) | about 2 years ago | (#39699611)

From the article:

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

I've been thinking about this for a while and I think we do need a new generation of IDE which isn't based around showing source files in tabs, but rather code snippets (functions, class definitions etc.) on some kind of desktop. When I'm debugging code I don't want to jump through X files, I just want to see the X related functions so I can understand the programs flow etc.

Re:Files are not the best representation of code.. (5, Interesting)

godefroi (52421) | about 2 years ago | (#39699663)

You mean, like Code Canvas?

http://research.microsoft.com/en-us/projects/codecanvas/ [microsoft.com]

Re:Files are not the best representation of code.. (2)

jamesbulman (103594) | about 2 years ago | (#39699755)

Yep, but without the eye bleeding UI ;)

Another benefit of moving away from explicitly managing files is that the computer is probably in a better position than the user to decide how to present the code to the compiler / linker. It could also have benefits in source control where you could track the history of an individual function better (imagine if someone refactors a function from one file into another).

Re:Files are not the best representation of code.. (2)

godefroi (52421) | about 2 years ago | (#39700029)

You could do that today, in some programming environments, anyway. Some programming languages / compiler combinations allow classes to be split among files, into individual methods, if desired.

Re:Files are not the best representation of code.. (1)

s73v3r (963317) | about 2 years ago | (#39701559)

Yes, but the programmer still has to do that splitting manually.

Re:Files are not the best representation of code.. (1)

FrootLoops (1817694) | about 2 years ago | (#39700127)

You mean, "You mean, like Code Canvas (minus the 'Microsoft')"? This is /. after all.

Re:Files are not the best representation of code.. (0)

Anonymous Coward | about 2 years ago | (#39699681)

Code without files, exists since a long time and it's called Smalltalk.

Re:Files are not the best representation of code.. (2)

hobarrera (2008506) | about 2 years ago | (#39699689)

This does seem sort of what LightTable seems to be aiming at, actually.

Re:Files are not the best representation of code.. (4, Informative)

robmv (855035) | about 2 years ago | (#39699843)

So, you want Smalltalk code browsers [onsmalltalk.com]. This IDE concept is nothing new, Smalltalk had that kind of code browising from the start and the concept of a live image where every code change is done in a live vm. The only thing I see new here is some "modern" "HTMLy" UI

Re:Files are not the best representation of code.. (1)

rsborg (111459) | about 2 years ago | (#39701797)

So, you want Smalltalk code browsers [onsmalltalk.com]. This IDE concept is nothing new, Smalltalk had that kind of code browising from the start and the concept of a live image where every code change is done in a live vm. The only thing I see new here is some "modern" "HTMLy" UI

If a Kickstarter project and a new IDE is what it takes to get these ideas more commonly used, as a former smalltalker, I'm all game. The "live VM" idea of Smalltalk was probably way ahead of it's time - with JITs and a much higher baseline of compute power even in smartphones, it's now high-time we start seeing code as beyond text files or db blobs.

I'm still waiting for a non-smalltalk VM to feature the power of the walkback.

Re:Files are not the best representation of code.. (1)

H0p313ss (811249) | about 2 years ago | (#39701849)

... The "live VM" idea of Smalltalk was probably way ahead of it's time - with JITs and a much higher baseline of compute power even in smartphones, it's now high-time we start seeing code as beyond text files or db blobs.

I'm still waiting for a non-smalltalk VM to feature the power of the walkback.

Sing it brother.

Re:Files are not the best representation of code.. (3, Interesting)

AdrianKemp (1988748) | about 2 years ago | (#39702633)

Why exactly do you want to see code as something other than what it is?

Abstraction layers lead to nothing but hassle...

Re:Files are not the best representation of code.. (1)

loufoque (1400831) | about 2 years ago | (#39700027)

Doesn't work with languages such as C++....

Re:Files are not the best representation of code.. (1)

jamesbulman (103594) | about 2 years ago | (#39700135)

There's no reason why it couldn't. The underlying code can still live in a collection of .h/.c/.cpp files, I'm just asking that the IDE present that code to the developer in a different way.

Re:Files are not the best representation of code.. (2)

loufoque (1400831) | about 2 years ago | (#39700189)

In C++, textual order matters.

Re:Files are not the best representation of code.. (1)

luis_a_espinal (1810296) | about 2 years ago | (#39700927)

In C++, textual order matters.

Which would (and can) still be retained in the underlying source code files. The visual representation at the IDE level *does not have* to be viz-a-viz with actual physical textual ordering of definitions and declarations.

How to get that in a useful manner, that's another question. After all, tools and enviroments like VB, VFP and PowerBuilder attempted to show code in snippets as opposed to walls of text. Attempted they did and the results were mixed. Sometimes it helped, sometimes it got in the way.

So, that is the trick, in the delivery of the concept. But the concept itself, it is not computationally impossible, not even with a PL where textual order matters.

Re:Files are not the best representation of code.. (1)

luis_a_espinal (1810296) | about 2 years ago | (#39700989)

So, that is the trick, in the delivery of the concept. But the concept itself, it is not computationally impossible, not even with a PL where textual order matters.

Responding/adding to my self:

1. Why does the screen shots have to sample LISP code? :)

2. Tools like this *might* enforce people to functions and methods that are smaller, with lower cyclomatic complexity and with better composition, cohesion and structure. It would be very hard to visualize a 300-line long spagetti wall-of-text-function ;)

Re:Files are not the best representation of code.. (0)

Anonymous Coward | about 2 years ago | (#39701365)

It would be very hard to visualize a 300-line long spagetti wall-of-text-function ;)

Not much harder then visualizing 300 line long functions (plus one more to glue them together).

This IDE sounds all exciting as long as you're working on a program that displays "Hey Chris!", not so much if you think of larger projects.

Re:Files are not the best representation of code.. (1)

luis_a_espinal (1810296) | about 2 years ago | (#39701423)

It would be very hard to visualize a 300-line long spagetti wall-of-text-function ;)

Not much harder then visualizing 300 line long functions (plus one more to glue them together).

This IDE sounds all exciting as long as you're working on a program that displays "Hey Chris!", not so much if you think of larger projects.

You are missing the point (the one about size of unit of code and complexity): A system consisting of 300-line long functions/methods/proc/anything is a PITA to work with. Yes, it could be visualized, but it will be of little help to the poor soul that happens to inherit such a system.

Or maybe I am misunderstanding the point you are trying to make. I'm being honest, we could be talking about completely different things.

Re:Files are not the best representation of code.. (0)

Anonymous Coward | about 2 years ago | (#39701687)

I meant line long functions, three hundred of them. As in, the result of factoring out shorter functions from 300-line long one.

Even if you go all higher-order and code-reuse on its ass and get it down to 50 functions (and 50 lines of glue), it's still a lot to visualize at once, especially since every of them are called half a dozen times with different parameters now.

And in relation to a response below ("Odds are I don't care about all 300 at the same time. I only care about a couple of them at once.") - it just becomes no more useful then usual code walking, and I guess latence of tracing thru those 298 inbetween the two you're inspecting is still there.

Re:Files are not the best representation of code.. (1)

s73v3r (963317) | about 2 years ago | (#39701595)

Not much harder then visualizing 300 line long functions (plus one more to glue them together).

Odds are I don't care about all 300 at the same time. I only care about a couple of them at once.

Re:Files are not the best representation of code.. (1)

am 2k (217885) | about 2 years ago | (#39700065)

That's still a textual serialization though, just with a different container. Since there is a one-to-one mapping between classes and files in Java, it already kinda does that.

Maybe there's a way to represent code with no text commands at all? CryEngine's Flowgraph already does that, but its solution is of limited use (it gets really messy with more complicated code).

Re:Files are not the best representation of code.. (0)

Anonymous Coward | about 2 years ago | (#39700151)

Personally I wouldn't mind something like Star Trek style coding.
AI-backed coding would be pretty interesting if done right.

Re:Files are not the best representation of code.. (1)

s73v3r (963317) | about 2 years ago | (#39701523)

I have to say, I hate having to jump around multiple files, and multiple places in the files, to be able to see something.

Re:Files are not the best representation of code.. (1)

thetoadwarrior (1268702) | about 2 years ago | (#39701691)

Sorry but that's a stupid idea. You don't have to hunt through files anyway if you have a decent IDE.

Re:Files are not the best representation of code.. (2)

firewrought (36952) | about 2 years ago | (#39702007)

From the article:

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

Trivially true: files aren't the "best" representation of code because the definition of "best" depends on context and goals (which shift constantly during a work session). That's a sort of non-claim. Absolutely true: files are a convenient serialization of code.

Some folks will look at the trivially true claim and think "Boo files! Let's do away with files altogether!". Then they will go off and develop something that throws away the absolutely true part of the claim [I'm looking at you Squeak, Centura SQL/Windows, Visual Basic, etc.].

Some will be smarter (or rather, more well-funded) and develop something that lets you have your cake [store data in text files] and eat it too [work w/alternate representations]. Despite all its drawbacks, XML has been a major enabler of this, and it has the advantage of playing nice with version control and other file management tools.

Some folks will be even smarter yet and figure out different ways to exploit the absolute truth: for instance, static HTML operates quite successfully on file based representation. That economy let it win the hypertext wars before they even began. Or as another example, the D programming language strengthens the meaning of the "file" as the logical unit of management (for instance, a private member is visible to all code within the same file, regardless of whether it's in a different class or not).

So I guess what I'm saying is... consider fad-ish claims carefully and try to place them in a more holistic perspective.

Re:Files are not the best representation of code.. (0)

Anonymous Coward | about 2 years ago | (#39702039)

Code Bubbles [andrewbragdon.com] looks pretty nice. Unfortunately it's for Java.

Interesting, but not new (0)

Anonymous Coward | about 2 years ago | (#39699619)

Most of what they showed is either already being done with different interfaces, or would be nearly useless with a large program. Visual Studio has had a feature where you can see all the variants of a function, the function documentation, variables required, etc. for years just by typing the function name. The live data view is cool, but I don't see it working as well when your call stack gets to a couple dozen layers, either it will have to expand to the point that you can't really see anything, or it will conveniently ignore little things like external resources and threading issues. This really looks like an attempt to build an IDE by someone who hasn't worked with an IDE before and thinks that vi or emacs is the best way to write code.

Re:Interesting, but not new (4, Interesting)

OG (15008) | about 2 years ago | (#39699971)

The creator was a PM on Visual Studio. He's had quite a bit of experience as both an IDE user and developer, so I'm willing to give him the benefit of the doubt that he's spent quite a bit of time thinking about usability.

Wish I had some mod points. (2, Interesting)

Anonymous Coward | about 2 years ago | (#39700171)

While I really like VS, there are some irksome points... namely that plugins are now fairly plentiful, but when it slows to a crawl, there's no way to tell which plugin is the culprit. Second is that half the times it crashes, it loses my settings.. I like VS on my left monitor with the nav panels on the left... code to the right, and my right monitor for running/previewing. It resets and that's annoying. That and the rare occasion I'm supporting a VB.Net project it crashes 5x as much.

That said, I can have a new web project to the "hello world" stage much faster than say Eclipse for a similar project. This isn't meant for flamebait, just my own opinion. I wouldn't mind seeing some enhancements, and hope this is a successful effort. Personally I'd love to see continued advancement for JS development, specifically with NodeJS in mind.

port of no return in sight? (-1)

Anonymous Coward | about 2 years ago | (#39699637)

http://www.ustream.tv/occupiedair

"while some of the plugins may remained closed" (1)

ciaran_o_riordan (662132) | about 2 years ago | (#39699677)

That's called "open core".

Pity.

Re:"while some of the plugins may remained closed" (1)

hackula (2596247) | about 2 years ago | (#39699775)

I was surprised they would come out and say this. Who the hell is going to donate their development time on this project if the creators are going to close down parts of the platform and charge them for it?

Re:"while some of the plugins may remained closed" (1)

dave420 (699308) | about 2 years ago | (#39700107)

The same people who are more than happy to code for, say, Windows or OS X.

Re:"while some of the plugins may remained closed" (0)

Anonymous Coward | about 2 years ago | (#39700207)

Hey, numbnuts, what part of Windows or OS X is MS or Apple accepting patches for that end up in the final product. And, no, MS Apple siphoning off OSS code to integrate into OS X doesn't count. God some people on this web site are complete idiots sometimes.

Re:"while some of the plugins may remained closed" (0)

Anonymous Coward | about 2 years ago | (#39700739)

God some people on this web site are complete idiots sometimes.

Welcome to slashdot. And by "some", you really mean the majority on slashdot.

Re:"while some of the plugins may remained closed" (1)

hackula (2596247) | about 2 years ago | (#39700315)

No one helps to code the core of Windows or OSX without getting paid. That is a reversed scenario.

Re:"while some of the plugins may remained closed" (1)

s73v3r (963317) | about 2 years ago | (#39701613)

People who either think it's extremely cool, or think that it would help them be more productive.

Netbeans has a kind of "instant view" as well (1)

art6217 (757847) | about 2 years ago | (#39699707)

Beside the usual runtime inspection of data structures, you can evaluate expressions in the context of the app being run, even those not existing in the app itself. And the evaluation includes calling the app's methods and modifying its state.

I'm not sure what's new here (1)

IICV (652597) | about 2 years ago | (#39699749)

I have to admit, I'm not really sure what's new here; you can do the same sort of thing in Visual Studio and Eclipse, as far as I know.

If documentation is available, Intellisense (or Eclipse's equivalent) will pop it up along with the function's parameters when you start typing.

If you want to play around with code, you can pause the debugger and see what happens in the Immediate Window.

If you want to search for a particular function, well, that's why you've got Google open in another window; it's a lot nicer than messing around in the IDE.

If you want to see how data is flowing through your functions, you can watch variables, which are less confusing; in the demo, variables get replaced with the current literal value, which might make you forget that there's actually variable there after a long coding session. I do admit that his idea of keeping track of what every function's state was when it was initially called and displaying that is interesting, but I'm not sure how that would work with loops or recursion (do you show the looped function multiple times?)

The only really interesting thing is this idea of pulling related functions next to each other so you can look at them all at once, but I'm pretty sure the rest of the functionality isn't very novel.

Re:I'm not sure what's new here (1)

Anonymous Coward | about 2 years ago | (#39700159)

If you want to search for a particular function, well, that's why you've got Google open in another window; it's a lot nicer than messing around in the IDE.

Or use Eclipse's search, which has several options for this (don't know VS).

If you want to see how data is flowing through your functions, you can watch variables, which are less confusing; in the demo, variables get replaced with the current literal value, which might make you forget that there's actually variable there after a long coding session. I do admit that his idea of keeping track of what every function's state was when it was initially called and displaying that is interesting, but I'm not sure how that would work with loops or recursion (do you show the looped function multiple times?)

Eclipse's debugger remembers parameter values, too. You can use that for the "drop to frame" step action.
Which set of values you get in a recursive call depends on which stack frame you drop into.

The only really interesting thing is this idea of pulling related functions next to each other so you can look at them all at once, but I'm pretty sure the rest of the functionality isn't very novel.

And you can do that manually in Eclipse by playing around with docking several editor windows side by side. BTW, Window->New Editor gives you a second editor for the same file.

Re:I'm not sure what's new here (1)

s73v3r (963317) | about 2 years ago | (#39701625)

While everything you said is possible, I find the interface used to be much, much better in this demo than having to hunt all over files to do the same thing.

Live debugging seems cool... (3, Insightful)

hackula (2596247) | about 2 years ago | (#39699759)

Live debugging seems cool, however, basically every other feature is already implemented better in Visual Studio, Eclipse, or Netbeans. Hell, I have 95% of the functionality in Vim already. Why not just make the live debugging a plugin to one of the more mature editors? It seems you would get a whole lot more bang for your development time that way.

Only for dynamic languages (1)

Hentes (2461350) | about 2 years ago | (#39700041)

Sure, you can do runtime code modification in Lisp, but this approach won't work with C++ or Java.

Re:Only for dynamic languages (2)

abigor (540274) | about 2 years ago | (#39700085)

Actually, certain debuggers have had "edit and continue", compile on the fly capability while debugging for C++ and Java since 2005 or so.

Re:Only for dynamic languages (1)

samkass (174571) | about 2 years ago | (#39700695)

In Java you can't make changes to a class structure (methods, parameters, etc) and still use "edit and continue". I assume the situation is even worse in C++. Thus it's more useful in debugging than development.

Re:Only for dynamic languages (1)

cpghost (719344) | about 2 years ago | (#39700705)

Most Common Lisp systems compile functions on-the-fly, and this means also each time you edit a function. Some C++ IDEs can also recompile the compile-unit on-the-fly as you go. Sure, recompiling a Lisp function may be a tad bit faster than recompiling a whole C++ compile-unit, but you won't notice this in practice, because compile-units tend to be pretty small(ish) nowadays.

Re:Only for dynamic languages (1)

Requiem18th (742389) | about 2 years ago | (#39701451)

I'm a dynamic languages fan and even I take offense at that. Static languages can do anything dynamic languages do and them some, they are just more verbose about it. It should be possible to adapt this IDE to C++ for instance.

Look at all that wasted space. (2, Insightful)

AdrianKemp (1988748) | about 2 years ago | (#39700203)

The day my IDE is more rounded corners and empty space than actual code is the day I quit programming forever.

Luckily, my "IDE" is vim. Works great, about 50x more useful and faster than anything else I've tried and is available to me no matter where I am or what operating system I'm on at a given time.

Re:Look at all that wasted space. (3, Funny)

Qbertino (265505) | about 2 years ago | (#39700337)

Luckily, my "IDE" is vim. Works great, about 50x more useful and faster than anything else I've tried and is available to me no matter where I am or what operating system I'm on at a given time.

Psst: You should try Emacs. Your productivity will skyrocket.
Just saying.

Re:Look at all that wasted space. (2)

chooks (71012) | about 2 years ago | (#39700983)

Emacs is a decent operating system, but it could use a better text editor.

Re:Look at all that wasted space. (1)

IICV (652597) | about 2 years ago | (#39701103)

You're right, it did!

But then I realized that all the extra productivity was going into writing Emacs macros so I went back to Vim :)

Re:Look at all that wasted space. (1)

Chemisor (97276) | about 2 years ago | (#39701403)

Psst: You should try Emacs. Your productivity will skyrocket.

Of course. Just use the simple command Ctrl+A+Shift+R+o+AltGr+s+k+y!
Emacs: the ultimate tool that lets a person use all three of his hands.

Re:Look at all that wasted space. (0)

Anonymous Coward | about 2 years ago | (#39700679)

I agree - I used Eclipse once (Blackberry - ugh!) and couldn't help but think that the IDE was designed to make developers as unproductive as possible by making it so cumbersome to do anything at all. I assume that eventually IDEs will become so intelligent that they won't allow you to edit your own code at all. The funny part is, I am lightning fast with my old Emacs + make stuff, and astound people with how fast I get code working.

Re:Look at all that wasted space. (1)

s73v3r (963317) | about 2 years ago | (#39701661)

Blah blah blah, coding hipster comment.

You forgot the part where you tell us to get off your lawn.

Re:Look at all that wasted space. (1)

Tom (822) | about 2 years ago | (#39702423)

Look at all that wasted space.

You should upgrade your display. Since I switched to a 27" display, I don't feel like screen space is valuable anymore. Very, very rarely do I use anything in fullscreen, because I simply don't need to.

Back when 14" was the standard, screen space was really valuable. Today? Get a bigger display.

Re:Look at all that wasted space. (0)

AdrianKemp (1988748) | about 2 years ago | (#39702511)

Yeah, just the fact that you said '27" display' tells me everything I need to know about you.

I have a great big 55" display that has a lower resolution than any of the three 21.5" ones sitting in front of me.

There are times I've considered a fourth...

But hey, it looks nice.. (1)

undulato (2146486) | about 2 years ago | (#39700263)

Opinion may be harshly (and indeed prematurely) divided on the actual usefulness or originality but at least we can agree that it's pretty.

Right?

Debugging features look nice (0)

Anonymous Coward | about 2 years ago | (#39700371)

I like the interactive "debugging" features that allow you to run selected functions from your code and see the results in realtime. Seems like he might be onto something there. Will be interested to see how it develops.

Browser based (2)

sugarmotor (621907) | about 2 years ago | (#39700401)

I've been using the frank gem with Ruby to see / explore effects of code changes in the browser.

The browser becomes a high-end output device (through frank's Auto-Refresh) for my text inputs.

That's not programming... (0)

holophrastic (221104) | about 2 years ago | (#39700575)

...that's scripting. Any time you can gain insight into your code by seeing variable values substituted for names, (which used to be called watched variables long ago), your code just isn't advanced enough to be doing anything legitimate. That's great and all when you're learning to program in school, and you were asked to use a few functions to make something happen. But that's not programming.

When, professionally, I write my own function, I can't make judgements based on actual variable values! A given function is called from at least three dozen places, and here's the kicker, in more than three dozen different ways. That not only means that flow paths change, but the actual value of a parameter can have drastic effects on what the function actually does. I don't mean that 3 becomes 30 and 4 becomes 40. I mean 3 becomes apple and 4 becomes an array of database results.

The entire idea of advanced programming is to use variable instead of actual values because programming is more powerful than markup. Because I can bring real intelligence to a function's operation.

And if I dared to modify a function based on a set of run-time values for one of those scenarios, I'd risk instantly breaking every other run-time scenario where that function is being called.

Now, if Light Table, or some IDE wants to show me every time my function is being called throughout my entire project, with every distinct set of parameters that it's ever received, and allow me to pair down the ones that I say are structurally identical, then yeah, that would have merit. Of course, it would be showing me about a hundred different scenarios for my one function, and would be based on weird run-time and user-input cases that simply couldn't be reproduced without actually running my entire project, so it would be impossible to simulate once I make one change to any other function anywhere else in my project.

Making things like this excellent academic learning tools, and nothing else. It simply removes the fundamental abstraction that is programming, and replaces it with information that I didn't need. I don't need documentation for a language that I use professionally. And I don't need to see the functions called by my function. Not only am I not able to comfortably change those sub-functions, but there are going to be at least fifty of those sub-functions if my code does anything impressive at all.

And you've consumed half of my screen real-estate.

Re:That's not programming... (0)

Anonymous Coward | about 2 years ago | (#39700865)

> That not only means that flow paths change, but the actual value of a parameter can have drastic effects on what the function actually does. I don't mean that 3 becomes 30 and 4 becomes 40. I mean 3 becomes apple and 4 becomes an array of database results.

Your code isn't "advanced" then, it just plain sucks. Learn about static typing sometime. Even Python and Ruby programmers at least try to stick to consistent types.

Re:That's not programming... (-1, Flamebait)

holophrastic (221104) | about 2 years ago | (#39701035)

Ah, static typing, that would be first year high school. Well done. Is your diploma mounted in your bedroom?

You might want to try intelligent functions. Functions with multiple optional parameters, and functions that take entire structures, consider environmental parameters, and maybe, just maybe, make some actual decisions on behalf of someone earning seven figures annually.

Let me know when you've written a function that tells a C.E.O. which three of thirty employees should be fired. That's a period, by the way. You get to figure out what that means, how it should work, and what to consider. Then you can tell me how simple your logic becomes.

Now, if you had said "learn about neural networks sometime", then at least you'd have been in first-year university.

Why don't you show me some code that no high school student could understand, no university student could write, and for which no employee could ever be accountable. Then you'll see what I do for a living.

Re:That's not programming... (1)

s73v3r (963317) | about 2 years ago | (#39701675)

You might want to try actually planning out your shit before you write it. Your program sounds like it would be something they give programmers in the 7th circle of hell to maintain.

Re:That's not programming... (1)

holophrastic (221104) | about 2 years ago | (#39701891)

Quite the opposite. a) clients and project requirements change year over year as they grow. So you need to change the function without changing everywhere it's called. b) the more intelligent the function, the more it can do. You, as a human, deal with varied input all the time. That's a part of being intelligent.

For example, something as simple as boolean = isBlank( string ). There are at least a dozen ways that a human being considers a string to be "empty". some of those depend on what that string looks like. certainly "" is empty, and "0" is not. false might be empty. "" might be empty. " " might be empty. "

" might be empty. "

" might be empty. A zero length array would be empty. As would a keyless hash. What about an array where each element is empty.

So what, you're going to have isBlankString() isBlankHTML() isEmptyArray() isBlankArrayElements() isBlankHashKeys() and a dozen others? And then you're going to remember how each is named, how to call each, what they do exactly, ...oh right, you're going to have six interfaces to your documentation.

I'm going to have isBlank(). And throughout my code, you'll see isBlank( aStrings ) isBlank( hKeys ) isBlank( myString ) and it'll be way easier to read, way easier to write, and then I'll kick it up to isBlank( oContact ) I'll check the telephone, e-mail, and name, to be certain that a "contact" can actually be "contacted" or I'll call it blank too -- since to a human being, it is. Even though it's a huge structure with a dozen other bits of data. And in six years, when my client wants to consider contacts with a company and position as sufficiently contactable, I'll simply change the definition of isBlank() the way that humans do.

My client's world isn't data-centric. It's business centric. So my logic functions are similarly so. As long as I keep them in-line with the client's business model, life is amazingly easy. And different for each client.

As for planning things out in advance, I plan for my client's business to grow, and hence change drastically. What do you plan for? A string remaining a string forever and never becoming a hash down the road? Everything becomes a hash eventually. Or do you plan to do all of the work for the hash from the start? And making it take six days to do something that only requires one day now, and may be thrown out long before that part is ever upgraded.

It's a very different way of thinking. That's what I charge for.

Re:That's not programming... (0)

Anonymous Coward | about 2 years ago | (#39702569)

Holy shit I hope I never have to work with code you write. You correctly identify that one single notion of "isBlank" won't apply, but the solution is not to define a global function that operates on every data type and changes whenever a client farts. That's just begging for unanticipated corner cases. "blankness" is a property of an object, so implement "isBlank" as a class or trait method:

trait CanBeBlank {
def isBlank:Boolean
}

abstract class Contact with CanBeBlank {
var name:String
var email:String

def isBlank = name.isEmpty && email.isEmpty()
}


Then later you can have a new class NamelessContact extends Contact containing a function definition override def isBlank = email.isEmpty() if you get a client that only cares if a contact has an email address.

Re:That's not programming... (1)

holophrastic (221104) | about 2 years ago | (#39702711)

once you go down the road of objects, I can't help you. enjoy your object hell. enjoy your definitions no where near the actual business logic that you write day to day. enjoy things acting differently from one minute to the next. I won't help you.

but the next time you, as a human not writing code, get handed a food and asked if it's a fruit, you can create a new neuron called NamelessFruit, and then check if it satisfies your seed clause. Me, I'll just look through my index of what makes a fruit a fruit. The way that humans do.

and if you think that for one second, when my client wants that change, that I'm going to extend a class, four files away from where I am, versus just adding a simple if condition to the one place where isBlank is defined, then you're going to expect me to charge my client for the two hours of work that it's going to take to adapt a few megs of code throughout a project, and then to test it, and then to write unit tests for it, and to update existing unit tests.

you'll also, very quickly in my world, have more than three dozen isBlank() functions, all very similar, but completely different. And good luck to you. Humans consider blank to be blank, not a version of blank that's different than a different version of blank. It's called cognitive compression, and it allows for abstract thought. you've killed that, because you now have close to sixty different isBlank functions.

Re:That's not programming... (1)

Requiem18th (742389) | about 2 years ago | (#39701483)

Yes, what we need is is live unit testing, nothing less would do. Except I'm sloppy and avoid TDD but that's my fault.

Re:That's not programming... (1)

holophrastic (221104) | about 2 years ago | (#39701601)

Unit testing isn't worse, but it's equally bad. If you can predict every combination of parameters relevant to the function, then your unit tests simply tell you when you broke your own function. I don't need help changing three lines of code. That was never the difficult part. I need help conceiving of complicated structures and not missing a given element.

If I could write the unit tests properly, I didn't really need them. So you wind up needing to test your unit tests for conseptual validity. It's turtles all the way down.

The whole point of abstract programming is to think abstractly. The moment you lose that, you lose the ability to do anything advanced. That's the skill. It's not about typing, and it's not about executing it in your head. About specifically about not executing it in your head.

Yeah that documentation trick is neat... (0)

Anonymous Coward | about 2 years ago | (#39700615)

Too bad it will never work. As of this day I haven't found a single development environment where installing the documentation into the IDE was not a pain in the ass. And all of them come in a form that is not easily extracted by other applications. Creators of the platform seem to have a vested interest in controlling distribution and presentation as much as possible.

- Visual studio needs a downloader/installer and a goddamn local webserver to even show .NET docs. And inline xml documentation is awfully verbose, maintaining it is a nightmare.
- Java IDEs need an archive filled with html page from oracle. Why it doesn't come with the JDK by default I'll never know. At least inline docs are sane.
- Flash documentation is a nightmare in just about every way possible.
- Unity, the game engine I'm working on right now, again uses a pile of html for its documentation, which comes with the installer.
- Last time I used c++, the best documentation was cplusplus.com, which of course was awkward to search and impossible to download for local use. (I might be wrong about that these days though. Don't know if there were any significant changes.)

I just don't see documentation like this becoming big unless everyone agrees on a common format for every language and every platform and make all documentation available for online and local use, no strings attached. This will never happen.

What if you want to program an IDE in the IDE? (1)

Lord Lode (1290856) | about 2 years ago | (#39700639)

Then you see an IDE in your IDE, in which you could create another IDE, and ...

Re:What if you want to program an IDE in the IDE? (1)

H0p313ss (811249) | about 2 years ago | (#39701861)

Then you see an IDE in your IDE, in which you could create another IDE, and ...

... we could call it Eclipse!

Getting there... (1)

Twinbee (767046) | about 2 years ago | (#39700751)

This is getting closer to what I've been hoping for.

Glad to see the realtime filtering of documentation too. That's something that's been missing from not just programming languages, but software and Windows in general (my own documentation [skytopia.com] for a program called opalcalc takes this to its logical conclusion at the bottom of the page).

What I'd really like to see though is not just real-time filtering of functions/methods/variables (each with their own metadata, so a word such as "exit" can be associated with "close" or "quit"), but ALSO where each function is ranked according to how much it's used. This will vary somewhat from person to person and program to program, but more often than not, some methods (and variables) from a class will be used much more often than others in general. It would be nice to see these at the top when given (often hundreds of) potential candidates.

Functions - not files - as smallest unit (1)

thereitis (2355426) | about 2 years ago | (#39700797)

I like the idea of working on a function at a time, not a file at a time. Code folding in VIM gets me part of the way, but searching for text unfortunately includes folded text and automatically opens the fold for me. Not what I want. Technically, functions shouldn't be that long to have to search but in reality, one has to work with 'fine' code sometimes. :)

But much code takes a while to compile... (0)

Anonymous Coward | about 2 years ago | (#39701325)

Something I was confused about in Victor's talk. The code he was editing seemed to be really short.

For my code, it takes a few minutes for the code to compile -- sometimes as long as 10 minutes if you're doing a full rebuild.

How could you use a tool like this in that context?

Re:But much code takes a while to compile... (1)

sugarmotor (621907) | about 2 years ago | (#39701993)

I think its fair to assume you use such a system when full rebuilds are not needed.

Such a system will work only with some software. For other software you would use a different system, or none at all. Software is just such a vast category.

Intermediate view is useful for *some* domains (0)

Anonymous Coward | about 2 years ago | (#39702499)

There are some times (such as HTML generation) where the intermediate results would be useful to see right away.

There are other times when they would just annoy you. If I've got an algorithm in mind and I have to type 20 lines of code, I don't want to be bothered by the panel on the right showing me all the stuff I know is wrong.

This reminds me of Google's dynamic search; but for code. I turn off dynamic search because it's too CPU intensive for my machine.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...