What I'd like for programming is a universal translator. Somebody writes a program in Java or Lisp, and I can read and modify it in Python and the author can read my changes in their own pet language. I write an Ant script and you can consume it with rubygems. You give me a program compiled into machine language or Java or .NET bytecode and I can read it in Python and run my modified version in the JVM, CLR, Mac, iPhone, Android, browser. Transparently, only looking at what the source language was if I get curious.
Toward a better programming
171–180 of 191 posts
Re: Toward a better programming
#172Earlier quoted context omitted.
Okay, how does \integral{\integral nasty expresion dx}dy} get implemented? (excuse the faux LaTex, I never remember the syntax)
Something like that (typing from memory): (defun do-integrate (tree var) ;; -- do some crazy symbolic manipulation on the source tree ) (defmacro integral (expr var) ,(do-integrate expr ,var))
I don't think I expressed my concern very well. The point is is that you often cannot just depend on some built in to do your mathematics for you - stability, speed, and convergence depend heavily on the implementation that you use. There is a huge gulf between symbolic expressions and how we solve them on a computer. For example, all we really know how to solve is Ax=b - linear equations. Oh, we have special tricks for some nonlinear cases, but a huge part of computer math is getting your system approximated as Ax=b, and then solving for that. You can't just hand wave that away by throwing symbols in your code.
People will bring up various symbolic and other specialized math packages. Sure enough, they exist. And, they are dog slow. They are used to explore problem spaces, and to get the solutions to small problems. But when it comes to it, we reach for C++, for Fortran (and now, maybe Julia) to get performant code. If I want to type equations and get results, why wouldn't I already be using one of those systems, heavily optimized for math computations of that sort? If I am in a general purpose language, it is because I need to specify the system in great detail, and obscuring it with symbols like sum and integrate just doesn't work.
And, in case the larger point is lost, this is an example to illustrate the larger case - that we can't really obscure large parts of the computational model. In cases where we can, we already do so. For example, I don't write my own red-black trees, I count on STL to do it for me. v.insert (make_pair("name", "Roger")) is a great abstraction (albeit verbose). But even when it comes to using something like BLAS & LAPACK, I have to choose the representation and so much more. Dense vs sparse, etc. So please don't retort with some integral or other math equation that can be solved efficiently with default methods - that misses the point. CS since the 50s has been a study of how to abstract concepts away, and have a done a fine job of it. A few pictures doesn't magically make the remaining problems disappear.
edit:
I somewhat know what I am talking about here. In my Ph.D program (left it, didn't graduate, not claiming a PhD) in the 80s my advisor was advocating an expert AI system to resolve these problems. Any guess as to the result of that research? The hint is that no expert system is built into any of our heavy math systems today. And just this week I sat through a session where a researcher was presenting early work he was doing no a DARPA grant to, wait for it, same thing, basically.
It's a outrageous, tremendously hard problem, and we keep getting people announcing that they have solved it, they just don't quite have the code running yet. Okay. Show me, don't tell me. A point-click interface to inject a sqrt symbol into my code, or an image of a playing card, is so far from the mark, both from the triviality of it, and the distance between that and a hard problem.
Re: Toward a better programming
#173Earlier quoted context omitted.
Text as code, for instance, is just an extension of a concept which has been around in one form or another since the scribes of ancient Babylon, or thereabouts. I can imagine more complex ways of representing code but I can't really imagine anything more efficient for translating human concepts into machine language. Except maybe direct, augmented telepathy, but even then people would probably think to the computer i…
The problem with code as text is not the visual representation but the manipulation. From the point of view of tooling for live-coding, it's incredibly painful to deal with an unstructured pile of text that at any given point may be in an invalid state (ie partially edited). Structured editing ( http://en.wikipedia.org/wiki/Structure_editor ) allows the tooling to deal with consistent, structured data whilst still ta…
Yeah, all those Structure-Editors and Node-Editors and Meta-Node-Editors and all those years and still more and more simple text-editors keep winning. My personal impression is that developers are actually moving away from those uber-tools, IDEs even and move toward vim plus shell tooling...
Re: Toward a better programming
#174Earlier quoted context omitted.
"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 represe…
Okay, how does \integral{\integral nasty expresion dx}dy} get implemented? (excuse the faux LaTex, I never remember the syntax)
It's like you didn't read what I said.
Re: Toward a better programming
#175Earlier quoted context omitted.
Good talk. I had all this stuff in the first chapter(the history) of my HCI-course at University. So, luckily, the younger programmers learn about stuff that already has been there, back in the days. But I was baffled by what bad stuff must have happened to the world, that we ended up where we are now and not where we should have been.
> But I was baffled by what bad stuff must have happened to the world, that we ended up where we are now and not where we should have been. UNIX spread into the enterprise world.
What is so bad ab out Unix and what would be an alternative?
Re: Toward a better programming
#176Earlier quoted context omitted.
> But I was baffled by what bad stuff must have happened to the world, that we ended up where we are now and not where we should have been. UNIX spread into the enterprise world.
What is so bad ab out Unix and what would be an alternative?
A world of command line interfaces and TTY text editors, instead of the powerful interactive GUI world Xerox PARC systems had.
Re: Toward a better programming
#177Hate to break it to you people, but rms was always right- the #1 reason why programming sucks is that everyone wants complete control over all of the bullshit they threw together and thought they could sell. Imagine an environment like a lisp machine, where all the code you run is open and available for you to inspect and edit. Imagine a vast indexed, cross-referenced, and mass-moderated collection of algorithm imple…
Locking down my code for economic reasons has worked pretty well for me. It's allowed me to have a pretty good lifestyle running my business for the last fifteen years and kept my customers happy because they know I have a financial incentive to keep maintaining my products.
and he's oh so healthy
in his body and his mind
Re: Toward a better programming
#178I 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…
> 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). Well yes, there are always people who stick to the older methods, or sometimes the situation calls for programming through a terminal window, but there have been big advancements since those methods, like the gre…
Given that Chris Granger was a program manager on the Visual Studio team, it seems likely he is aware of what it provides and does not consider it an adequate solution. It may not even be a step on the path to an adequate solution.
Re: Toward a better programming
#179Earlier quoted context omitted.
Something like that (typing from memory): (defun do-integrate (tree var) ;; -- do some crazy symbolic manipulation on the source tree ) (defmacro integral (expr var) ,(do-integrate expr ,var))
I don't think I expressed my concern very well. The point is is that you often cannot just depend on some built in to do your mathematics for you - stability, speed, and convergence depend heavily on the implementation that you use. There is a huge gulf between symbolic expressions and how we solve them on a computer. For example, all we really know how to solve is Ax=b - linear equations. Oh, we have special tricks…
My points where 1) that these kinds of concerns are entirely orthogonal to whether we limit our expression to ASCII symbols, and separately 2) that there can be useful things done with analytic forms even when we aren't able to turn them directly into machine code.
Re: Toward a better programming
#180Earlier quoted context omitted.
> 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). This seems like an almost willful misunderstanding of what programming is. The power of programs does NOT come from their syntactic structure. The power of programs comes from the non-linearity of programming lan…
One of my favorite CS professors back in the 80s used to joke that we had gone from cave paintings to written language, and now we wanted to back with our computers. (my paraphrase of whatever he actually said back then) Pictographs work for the illiterate, but that doesn't make them the most efficient interchange mechanism.
A professor I knew had a good way to put it: "With the shell, you have a language. With pointy-clicky, you're reduced to pointing at things and grunting."
While I enjoy the shallow dig, I think this is a pretty great metaphor generally, in a deep (and less condescending) way.
If you drop me in France, and I don't speak French, I'll probably do a lot of communication with pointing and grunting, and I'll probably be able to accomplish simple tasks (particularly with an ideographic picture book on hand). Expressing more complicated things that way is pretty intractable, however. Learning to speak French is the solution, but it's a lot of work.
Moreover, there are certainly contexts where pointing makes more sense ("I'll take that one, that one, and that one" versus trying to pick out differentiating features or count).