I love Chris Granger's work, and LightTable, but jeeez my eyes were going weird by the "Chasing Local Maxima" section. Turn the contrast down!
Toward a better programming
11–20 of 191 posts
Re: Toward a better programming
#12I am optimistic about our field.
Things have not stayed stale for the past 20~30 years, in fact, state of programming have not stayed stale even in the recent 10 years.
We've been progressively solving problems we face, inventing tools, languages, frameworks to make our lives easier. Which further allows us to solve more complicated problems, or similar problems faster.
Problems we face now, like concurrency, big data, lack of cheap programmers to solve business problems were not even problems before, they are now, because they are possible now.
Once we solve those problems of today, we will face new problems, I don't know what they would be, but I am certain many of them would be problems we consider impractical or even impossible today.
Re: Toward a better programming
#13There's a reason the game Pictionary is hard, despite the "a picture is worth a thousand words" saying. And that is that images, while evocative, are not very precise. Try to draw how you feel.
If you are using card[0][12] to refer to Card::AceSpades, well, time to learn enums or named constants. If, on the other hand, the array can be sorted, shuffled, and so on, what value is it to show an image of a specific state in my code?
There's a reason we don't use symbolic representation of equations, and it has nothing to do with ASCII. It's because this is implemented on a processor that simulates a continuous value with a discrete value, which introduces all kinds of trade offs. We have a live thread on that now: why is aaaaaa not (aaa)(aaa). I need to be able to represent exactly how the computation is done. If I don't care, there is Mathematica, and and the like, to be sure.
If you disagree with me, please post your response in the form of an image. And then we will have a discussion with how powerful textual representation actually is. I'll use words, you use pictures. Be specific.
Re: Toward a better programming
#14There's a reason the game Pictionary is hard, despite the "a picture is worth a thousand words" saying. And that is that images, while evocative, are not very precise. Try to draw how you feel. If you are using card[0][12] to refer to Card::AceSpades, well, time to learn enums or named constants. If, on the other hand, the array can be sorted, shuffled, and so on, what value is it to show an image of a specific state…
It's not about choosing one or the other, it's about allowing both. I can use symbols (though not sentences or other usefully descriptive language), but do I have an opportunity to represent those symbols at all? no.
I'm not saying we should forsake language, if you look at the now very out of date Aurora demo, all the operations have sentence descriptions. This certainly isn't an all or nothing thing. If it makes sense to visualize some aspect of the system in a way that is meaningful to me, I should be able to do so - that is after all how people often solve hard problems.
Re: Toward a better programming
#15I have a tremendous respect for people who dare to dream big despite all cynicism and common assumptions, and especially people who have the skills to actually make the changes. Please keep doing the work you're doing.
Re: Toward a better programming
#16Sadly I feel that LT has jumped the shark at this point. What started off as a cool new take on code editors has now somehow turned into a grand view of how to "fix programming". I can get behind an editor not based around text files, or one that allows for easy extensbility. But I can't stand behind some project that tries to "fix everything".
As each new version of LT comes out I feel that it's suffering more and more from a clear lack of direction. And that makes me sad.
Re: Toward a better programming
#17I alternate between thinking that programming has improved tremendously in the past 30 years, and thinking that programming has gone nowhere.
On the positive side, things that were cutting-edge hard problems in the 80s are now homework assignments or fun side projects. For instance, write a ray tracer, a spreadsheet, Tetris, or an interactive GUI.
On the negative side, there seems to be a huge amount of stagnation in programming languages and environments. People are still typing the same Unix commands into 25x80 terminal windows. People are still using vi to edit programs as sequential lines of text in files using languages from the 80s (C++) or 90s (Java). If you look at programming the Eniac with patch cords, we're obviously a huge leap beyond that. But if you look at programming in Fortran, what we do now isn't much more advanced. You'd think that given the insane increases in hardware performance from Moore's law, that programming should be a lot more advanced.
Thinking of Paul Graham's essay "What you can't say", if someone came from the future I expect they would find our current programming practices ridiculous. That essay focuses on things people don't say because of conformity and moral forces. But I think just as big an issue is things people don't say because they literally can't say them - the vocabulary and ideas don't exist. That's my problem - I can see something is very wrong with programming, but I don't know how to explain it.
Re: Toward a better programming
#18There's a reason the game Pictionary is hard, despite the "a picture is worth a thousand words" saying. And that is that images, while evocative, are not very precise. Try to draw how you feel. If you are using card[0][12] to refer to Card::AceSpades, well, time to learn enums or named constants. If, on the other hand, the array can be sorted, shuffled, and so on, what value is it to show an image of a specific state…
It's not about choosing one or the other, it's about allowing both. I can use symbols (though not sentences or other usefully descriptive language), but do I have an opportunity to represent those symbols at all? no. I'm not saying we should forsake language, if you look at the now very out of date Aurora demo, all the operations have sentence descriptions. This certainly isn't an all or nothing thing. If it makes se…
In your example you used an ace of spades. Your picture took up half my screen. I can't imagine trying to actually manipulate logic when each element is taking up half my screen - can you?
Instead, I can just create a variable called AceSpades. It's not as... philosophical? but it's a million times more practical. Instead of needing an artist to come and draw up a new symbol for a concept I've created, I can just write it in text as a variable name. A lot of graphically based languages have been tried but they just don't scale to general problems. They work extremely well as limited languages for very constrained problems, but as soon as you need a new concept the complexity goes out the window compared to a traditional text based language. Why? Same reason as before - defining a concept in text is easier than designing a new symbol.
You touch on this in your blog too in how most of what programmers do is glue things together. You didn't really define what "glue things together" means though. I think it means "define new concepts using existing concepts". Eg, we take a MouseInput and a Sphere and create a new SphereSlice. With a text language we're just glueing the input library together with our geometry library. With a symbol based language, we have to actually define the new symbols and concepts of what a slice of a sphere is.
Re: Toward a better programming
#19There's a reason the game Pictionary is hard, despite the "a picture is worth a thousand words" saying. And that is that images, while evocative, are not very precise. Try to draw how you feel. If you are using card[0][12] to refer to Card::AceSpades, well, time to learn enums or named constants. If, on the other hand, the array can be sorted, shuffled, and so on, what value is it to show an image of a specific state…
"There's a reason we don't use symbolic representation of equations, and it has nothing to do with ASCII. It's because this is implemented on a processor that simulates a continuous value with a discrete value, which introduces all kinds of trade offs."
I think that's wrong. I think the reason we don't use symbolic representations is entirely due to a preference for ASCII. Whether relying on just the symbolic representation would be sufficient depends on domain - sometimes I don't care about the precise FP value (-ffast-math exists for a reason), maybe I'm working with bigints instead of floats, maybe ... But having the ability to specify and talk about the symbolic version seems only helpful - maybe some combination of static analysis and testing can make sure my implementation matches it?
Edited to add: Of course, whether it is helpful enough for the added difficulty specifying it with typical UI is another question.
Re: Toward a better programming
#20I wholly agree with this article. The exact point the author is getting at is something that I have been trying to say, but rather inarticulately (probably because I didn't actually go out and survey people and define "what is programming and what is wrong with it").
I really can't wait for programming to be more than just if statements and thinking about code as a grouping of ascii files and glueing libraries together. Things like Akka are nice steps in that direction.