| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Comments:
<0> http://subtextual.org/OOPSLA05.pdf Section 3.2
<0> drewp: well, that's a narrow thought. I constantly need to rename bad names at work, and I get yelled at every time something breaks because of it. But it must be done or the interfaces accumulate yuckyness
<0> and its only been possible since we moved to work on one branch. Renaming in a text-based language with multiple branches is almost impossible
<1> so you should change your practice to something that lets external users of the names continue to work, but lets you (and new code) use the good names
<1> section 3.2 sounds equivalent to "we're going to make namespaces so you can stop worrying about uniquifying" (which i like) and "you don't have to type camelcase names as often because we're going to let you click around", which might be nice but has questionable scalability
<0> drewp: the problem is, that would mean that a lot of the infrastructure/work would accumulate these nasty adapters making it much harder to add things and maintain. I'd rather suffer 5 man-hour breakages a week for a few weeks than have a lot of code with a lot of yucky compatability adapters and uglyness layers all over it
<0> drewp: why does not requiring camelcase have much to do with scalability?
<1> Peaker: i tossed in camelcase because he thinks "otherUsesOfNames" is a problem. i realize that python and others like names to fit a certain syntax, but i think that's a reasonable burden to put on the programmer
<1> Peaker: my scalability concern is that when things get really big, clicking on things will become hard, and if everything happens to be called "foo", you'll have a hard time finding the right foos to connect
<0> drewp: every burden is "reasonable", but its all relative. I agree names as names are not a huge burden. but A) any burden lifted from the programmer increases produtivity, B) names themselves have many indirect burdens, like limiting refernce-abiltiy of things (like values inside functions), and requiring refactoring and yucky adapters for compatbility
<1> the problem you're having at work is definitely worth addressing, but i don't think hiding the names of everything and letting people put their own arbitrary labels on the values is the answer
<1> wait, i only claim that "otherUsesOfNames" vs "other uses of names" is not a big burden
<0> drewp: I think the main flaw with subtext as he presents it, is that he tries to make it into a mousy-thing. Sure you can use the keyboard to find the objects you want, and sure it can even be done by their name, but the main issue is that the reference is kept correct even if the name is changed
<0> drewp: There's no hiding of the names, its simply ceasing to use them as the way to reference stuff
<0> drewp: and ofcourse if everything is called foo you'll have a hard time, but that's true with ordinary names inside separate namespaces too
<1> i'm using 'name' like python does, and in subtext you don't see those names; only user 'labels' (as rdf calls them)
<1> i think my point where 'everything is called foo' is just as true when 'exactly the two things i want to distinguish are both called foo'
<0> but the labels are equivalent to names in their positive features, they just don't share the negative features (of being used as references)
<0> I think you are reading too much into his salary example, which is a bad example..
<0> you're not supposed to use the same label multiple times, and the ability to do that may be or may not be a good idea, its surely not good practice
<0> (in the same context, anyhow)
<1> well ok- the 'good practice' will be to use a different label on things that a programmer will later want to distinguish
<0> btw, you could use icons in your interfaces instead of names for better clarification (just like toolbars in many apps)
<1> and that sounds really close to what we do today in python, since python has a pretty good amount of namespacing
<0> Yeah, labels aren't there to provide NEW positive features over names. They are there to provide the SAME positive features, just without the negative ones
<0> Why do you believe Python's closures cannot modify the enclosing namespaces?
<1> and i think namespaces (especially ones provided by the language) are addressing that problem already
<2> The Blender UI does this too-- objects have names for the gui, but the reference is actually through another pointing mechanism. But you still end up with a rats-nest of names and pointers which are no more decypherable than a POVRAY scene description.
<3> Heh
<0> hari`: it doesn't break when you rename it, and it lets you write to variables from the outer scope :)
<1> hari`: so for the current discussion, call the GUI ones labels. Can you just work in terms of the labels? Do labels solve the problems that subtext claims to solve?
<0> What do you think about (let ..) ? Do you agree there is currently a tradeoff between (let ..) and implicit scoping? I believe subtext makes the tradeoff moot as you get the advantages of both approaches
<1> Peaker: python's particular scoping rules might not be ideal, but we can imagine a python where they are fixed in whatever way you want. I still don't see the big added value of subtext-style names/labels
<0> drewp: they cannot be "fixed" because it is a tradeoff. You gain scope-access, you lose conciseness of functions
<0> in subtext, I have both scope access and concise functions/representaitons
<1> scope access is via 'state' and comp***es, right?
<0> Not sure what you mean by "state", but its via comp***es or other visual aids to show where the references are.. Hell, it can be colored names or such
<0> green 'x' vs blue 'x' for the two x's in two contained functions
<1> guh
<0> guh?
<1> well whatever. i claim it's good enough to use somehting like scope1.x and scope2.x (not that python has this), and that colored labels are not an interesting step forward
<0> I think colored names to show the user how the name "conflicts" are actually being resolved is much much nicer than nested let's or placing restrictions on the name conflicts in the first place, resulting in the un-embedability of code within other code
<1> and scope1 might change its name someday, and the system should rewrite my code (just like your colorful system "rewrites" the code to work when a label changes)
<0> the color names are not a very interesting step forward I agree, but they are a product of an interesting step forward, only possible if that step is taken, like many other featres
<1> ok, so let's temporarily exchange the color-gui for text code, and make a system that knows how to update one section of code when aonther section changes
<0> drewp: You are now proposing a scheme to enrich the text backend to be able to contain all the information that subtext encodes. That is a good idea, but again you are limiting yourself to the current model you are using, and any new feature will be limited by this backend's richness. If your editor shows you something else than the text stored, why store it as text at all?
<1> that sounds like it has all the value, with possibly more clutter in the code (since there are no colors), but it would be lots easier to put into today's systems
<2> drewp, no, the names don't really solve anything (but it does enforce uniqueness in a given namespace), but that may not be the fault of the labels-vs-references.
<4> hmmm
<4> looks like the compiler module is pure python, awesome
<4> but it depends on parser, which isn't
<4> still, finding a pure python parser shouldn't be too hard
<0> drewp: If you're talking about practicality of integration in current systems, I agree. But I am more interested in the "ideal programming environment" and perhaps more, and don't want to see it restricted by compatability concerns
<1> Peaker: i tihnk it's obviously better to integrate new ideas into current systems, and then do it in a way that can become the IPE later. today's systems ****, but many of the requirements that led us to them will still be requirements of the IPE
<0> drewp: the problem is that a textual backend is insidious
<1> so, if the IPE is letting external names change while keeping your code working (which is the solution to your problem at work), let's see that ASAP. it has lots of complicated issues
<0> I think our minds in the computing field are so very trapped in misguided concepts that escaping them will help us create better
<0> drewp: it cannot work because of branching, without a very complex tracking system
<1> Peaker: sure, but we're only replacing a textual backend if we have something that's completely as capable (and better). Showing off non-text systems that aren't as capable is not very interesting to me
<0> drewp: its not enough to fix all current code, you need to fix all the merges later
<1> yep- those are some of the complicated issues
<0> drewp: I agree that subtext is not what we want to switch to tomorrow. But I do think its much better to use an unrestricted platform for research. It might be a good idea to "backport" these ideas to current environment, learn about them before implementing a new environment
<1> i welcome a subtextual demo that attacks those issues, and then i hope we might be able to incorporate some of those ideas into our crappy current systems if possible
<1> sure
<0> Do you agree though, that there's no reason that in 30 years from now, we'll still be programming by writing text, or even, have our editors spout out text as the backend storage for the programs?
<1> i think we don't HAVE to be using text, but there are various reasons to predict that text will live for 30 years
<0> text storage backend for program code will cease to live by then.. I am willing to make a bet on that one :)
<1> while it's fine to do research on unrestricted systems, my money is on systems that appear to not be using text, but remain compatible with text-ful systems
<0> compatability can be via FFI and such
<1> i mean more than that
<0> why do you need more though?
<1> (just as while the final storage might be xml, we're not calling that 'text' :)
<0> true true, though I doubt xml will survive 30 years, it ****s :)
<1> so that i can mix text-ful tools with text-free tools
<0> well what tools do you use for example, and would want to keep?
<1> like, subtext might become downloadable, and really awesome, but it doesn't have a way i can make a patch over an ssh console link. That would be a reasonable thing for subtext to not care about,
<1> but i might be in a position where i really care about that capability
<1> barbaric though it may be
<0> hmm, a patch is just data, even a subtext one. I'd be surprised to find a mature subtext-like system not having that capability
<1> so then, when we have two systems-- subtext, with total gui and no usable text version; and drewtext, with total gui plus a text version-- which one is going to win?
<1> more than a patch, then, something where i need to play with the code and clone some stuff and write a new low-level function. whatever
<0> its not so simple, drewtext will have to make many sacrifices in order to remain compatible with text.. For one, it will have a lot more code to function at all..
<0> drewp: you'll use the curses view then ;-)
<0> drewp: after all, with text you would use a text editor, which would be one of two, wouldn't it? :)
<0> all the nice icons will have to be shown their alt repr's..
<1> my "patch the code over ssh" example might be weak, but i think that in general, adoption favors the systems that take smaller steps away from current practices
<1> now that might keep things ****ing for longer, but it means that if we actually want to see subtext in use, we should think about the smaller steps
<0> I agree, but I think a major drastic change is needed in almost every aspect of computing.. OS's, GUI's and programming
<1> it would be nice, certainly, but i can't argue that it's "needed"
<0> well, computers at large are not "needed"
<1> and therefore, the change that we'll actually buy is the smaller one. Hopefully it's in the *direction* of the drastic change
<1> and that's why i am in favor of projects like subtext, since they tell us what to move towards
<1> (except i don't actually like subtext yet, so i am less in favor of it in particular :)
<0> Maybe you're right, it might also help people eventually realize why they want to move. Or maybe it will wrongly convince them they are already enjoying the improvements
<0> heh yeah his view is his main concept, and its a bit lame. But the concept is great. I wish I had some time to explore other views for a subtext-like model
<1> i think the Big Problems today are that non-programmers can't make good, simple programs without tons of pain, and that code reuse consists of text copy-paste
<0> I very much hate the use of the mouse. I think it sends the message that subtext is necessarily slower to program, if you're a fast typist. After all, it takes a lot less keystrokes with the keyboard to write factorial in python or Lisp. Obviously optimizing keystroke count is more possible with an arbitrary backend and arbitrary view though
<1> subtext certainly has interesting ideas for both of my problems, but i don't think those demos are that close to where i want to be goign
<0> where do you think we should be going to solve these problems?
<1> apple automator, while i've never used it, seems like it might be a good step towards #1
<0> How does it work, in general?
<1> i've mostly read its website :) i think it's giant-sized building blocks that can p*** data, practically like unix shell pipelines (but with better data typing)
<1> and with well-crafted blocks, it does seem like non-programmers could solve a lot of their problems
<1> now, creating the good blocks and deploying them, etc, those have always been big problems and i don't know how well apple automator is doing, there
<0> doh
<0> <1> apple automator, while i've never used it, seems like it might be a good step towards #1
<0> [03:40] <0> How does it work, in general?
<1> dang
<0> cool! that was very similar to my idea of replacing all the silly GUI's everyone is writing with a unix-pipe like model of gui components you connect like pipes
<1> as to #2 (most code reuse consists of text copy-paste), i think refactoring and checking tools could help a lot, and we're just barely seeing them today
<0> that was when I realized that such components connected by pipes, are merely another view to the same subtext model (!)
<1> yeah, i think gui components+pipes is sometimes called "5th-gen languages"
<0> the subtext components are merely very low-level.. if you replace them with mp3-decoder, and mail sender, then the model makes sense as a desktop and automation tool
<1> anyway, total refactoring+checking doesn't mean we have to ditch text, but it does mean we should rely less on text editors
<1> yes, i like that aspect of subtext fine. I'm interested in how Real Programmers make use of apple automator tasks
<0> text editors have a REALLY hard time constantly parsing the code, as it transitions from two valid states by going through a lot of invalid states. Its hard to guarantee that the two valid states are semantically equivalent, as it is possible with a nontextual backend
<5> Hi guys. If anyone is familiar with the tkinter Canvas widget - I have, what I think is, a very simple question.
<1> to me that doesn't say "we must eliminate the text program" but rather "we need program editors that are a LOT smarter than text editors"
<0> Gfn: just ask it? :)
<5> I gotta type it :p one sec
<0> drewp: but not only do they need to solve the problem we speak of, they also need to solve the problem of compatability with text, of transitioning through invalid states, of deciphering complex semantics.
<5> I have a bunch of "small values" that I'm drawing onto the canvas - I need to "zoom in" on the region which is drawn. I tried using the Canvas.Scale method, but I'm not using it right?
<0> For example, how can a refactoring tool rename something in Python, where it cannot even know if someone eval'd or getattr'd dynamically?
<0> Gfn: not sure about scaling in a tkinter canvas.. What I can tell you is I tried writing a game with it, and gave up and moved to pygame eventually
<1> Peaker: that's impossible, of course, but i think the tool could be successful even if it said "no guarantees on evals or getattrs"
<5> ug :| thanks for answering though
<0> drewp: the slightest chance of breakage would make many weary of hitting the button
<1> Gfn: scale is limited, but it can work. note that text will stay at the same point size, etc. One of my scale-using programs is at bigasterisk.com/skim (i think)
<0> in Python the problem is even worse.. Without static typing, you cannot rename an attribute even if it is only used statically
<5> drewp, checking it out now :D
<0> anyhow, I gotta go sleep. Was an interesting one. Good night
<1> http://cvs.bigasterisk.com/viewcvs/skim/src/zooming.py?rev=1.3&content-type=text/vnd.viewcvs-markup has an awkwardly-named scale function that calls canvas scale
<5> yep I'm checking it out right now as we speak :)
<1> i can probably answer yuor questions better than that code can
<5> ok well then let me explain a bit better
<5> I have a whole bunch of values, most of which are in the range 0-1, i need to plot them on a canvas widget, but if I plot my initial values, I end up with a giant dot :p (obviously), So I need to scale it up quite a bit, and I'm not clear what a good way would be to do that
<5> kittens are so cute when they're sleeping. she gets up, jumps on me, curls in my lap and goes back to sleep
<1> many of my programs have a transform(pos) method that turn my coordinate system into the canvas coord system, and that's where i normally cause 0..1 to draw as 50..600 or whatever
<5> any idea how i'd go about doing that?
<1> i find canvas's coordinate support to be a little too weak to handle all those issues for you
<1> oh, in skim, i called that method world2canvas. (but i now think that's a lousy name)
<1> also, i used my own silly Pair object instead of using Numeric, which is what i normally use for vector math
<5> I see that ;)
<1> http://darcs.bigasterisk.com/light9/light9/zoomcontrol.py is a similar thing i wrote more recently, but it can get away with floats since there's only one dimension
<1> man, i rewrite this stuff a lot
<1> http://darcs.bigasterisk.com/light9/light9/curve.py:230 is one i wrote more recently
<1> or even http://darcs.bigasterisk.com/gasuse/linegraph.py:56 (not tk canvas, but the same issue)
<5> return (p[0]-start)/(end-start)*self.winfo_width(), (ht-5)-p[1]*(ht-10)
<5> , mind breaking that down for me?
<5> p[0] is the x, p[1] is the y, ht is the height of the canvas?
<1> Gfn: it's making a new x,y coordinate pair for canvas space
Return to
#python
or
Go to some related
logs:
#web
flash player x86_74
#perl
#centos
phpbb exploits
facefacefaceface
zokum
#lisp
invalid PORTDIR_OVERLAY
gentoo mplex emerge
|
|