http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3367 <pre> yep. I was left previously trying to figure out whether "thinking using text" was more linguistic/verbal or visual thinking, given it doesn't really match well with either: verbal thinking is generally described as people thinking with words and sounds; visual thinking is generally described as pictures / colors / emotions / ... so, one can wonder, where does text fit?... granted, yes, there is some mode-changing as well, as not everything seems to happen the same way all the time, and I can often "push things around" if needed (natural language can alternate between auditory and textual forms, ...). I have determined though that I can't really read and also "visualize" the story (apparently, many other people do this), as all I can really see at the time is the text. probably because my mind is more busy trying to buffer up the text, and the space is already used up and so can't be used for drawing pictures (unless I use up a lot of the space for drawing a picture, in which case there isn't</pre> BGB 2012-05-09T12:48:39 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3366 <pre>Yeah, Martin is always quite good at explaining these things... I found most of his works quite confirming. The trouble seems to be (and this is an issue I have with computers) as Alan points to... (but perhaps broader than he intended)... Optimisation should be separated from Intent Expression. Higher level languages are, by definition, to aid humans in understanding - and yet they are themselves not able to be decoded / de-composited. For CRAP's sake, we use the word "code" to talk about programming... but that's not what it should be... imagine a world of layered information processing systems... all dealing with a tiny slice... all smalltalk-like compiled down to optimised systems behind the scenes...(ie on the fly compilation and optimisation)... At its most useful, each "system" should be a machine that uses its own language, defined for inspection in the system itself... and explains its requirements... each tiny bit of code should be expressed in no more than a paragraph. This would then enge</pre> Julian Leviston 2012-05-09T07:43:45 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3365 <pre>There is an excellent video by Feynman on a related note: http://www.youtube.com/watch?v=Cj4y0EUlU-Y A damn good way to spend six minutes IMO... Cheers, Jarosław Rzeszótko 2012/5/9 BGB &lt;cr88192-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; </pre> Jarek Rzeszótko 2012-05-09T07:13:19 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3364 <pre>Yes, your description of the "thought clearing process" is very accurate, the main point being two interesting issues this process raises: A. Considering that the pseudo-code could have contributed more to my understanding of the problem that the final code, how much is lost by not having such "intermediate" artefacts somehow be part of the final code? What would be the best way to incorporate them? There is a partial analogy in mathematics where the mathematicians job is pretty much generating proofs but there is much less information about how those were discovered. B. Can programming languages be "brought" closer to the way we think yet still stay executable by the computer... ? (So that A is not relevant anymore) B1. ... via a particular programming style? B2. ... by an appropriate design? Such division helps to systematise some of the approaches you already mentioned. For example, with literate programming which implements a solution to A) I could keep the pseudo-code as part of the program in an </pre> Jarek Rzeszótko 2012-05-09T07:11:35 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3363 <pre> in my case I think my thinking process is a good deal different. a lot more of my thinking tends to be a mix of visual/spatial thinking, and thinking in terms of glyphs and text (often source-code, and often involving glyphs and traces which I suspect are unique to my own thoughts, but are typically laid out in the same "character cell grid" as all of the text). I guess it could be sort of like if text were rammed together with glyphs and PCB traces or similar, with the lines weaving between the characters, and sometimes into and out of the various glyphs (many of which often resemble square boxes containing circles and dots, sometimes with points or corners, and sometimes letters or numbers, ...). things may vary somewhat, depending on what I am thinking about the time. my memory is often more like collections of images, or almost like "pages in a book", with lots of information drawn onto them, usually in a white-on-black color-scheme. there is typically very little color or movement. som</pre> BGB 2012-05-09T01:07:49 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3362 <pre>By the way, This paragraph from Graham's essay, and in fact, his constant reiteration of it in most of his work, is perhaps the most under-rated idea that we have in the programming industry. It's actually not just the programming industry... My emphasis added: You can magnify the effect of a powerful language by using a style called bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages for those above. If you do this right, you only have to keep the topmost layer in your head. This isn't just a style - it's programming to a micro-interface, and programming in extremely tiny chunks... it's also what FONC seem to be doing with the idea of POLs and Ometa translating between them. The interface *is* the micro-language... what's inside the interface is simply the implementation of the micro-language. (or POL, if you like). One technique I use that is particularly helpful is naming my "variables" really long descriptive names. Effectively I use vari</pre> Julian Leviston 2012-05-08T22:58:10 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3361 <pre>Hi Jarek I think your main point is a good one ... this is why I used to urge Smalltalk programmers to initially stay away from the libraries full of features and just use the kernel language as a "runnable pseudo-code" to sketch an outline of a simple solution. As you say, this helps to gradually find a better architecture for the more detailed version, and perhaps gives some hints of where to look in the library when it is time to optimize. This was perhaps even easier and nicer in Smalltalk-72 where you could make up on the fly a "pseudo-code that actually ran and could be debugged" (and it had almost no library full of features....) This is one of many good arguments for finding ways to "separate meaning from optimization" Cheers, Alan &gt;</pre> Alan Kay 2012-05-08T22:51:42 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3360 <pre>Isn't this simply a description of your "thought clearing process"? You think in English... not Ruby. I'd actually hazard a guess and say that really, you think in a semi-verbal semi-phyiscal pattern language, and not very well formed one, either. This is the case for most people. This is why you have to write hard problems down... you have to bake them into physical form so you can process them again and again, slowly developing what you mean into a shape. Julian On 09/05/2012, at 2:20 AM, Jarek Rzeszótko wrote: </pre> Julian Leviston 2012-05-08T21:56:35 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3359 <pre>Natural languages are commonly much more ambiguous and you could say "fuzzy" (as in fuzzy logic) than (currently popular) programming languages and hence switching between those two has to cause some difficulties. Example: I have been programming in Ruby for 7 years now, for 5 years professionally, and yet when I face a really difficult problem the best way still turns out to be to write out a basic outline of the overall algorithm in pseudo-code. It might be a personal thing, but for me there are just too many irrelevant details to keep in mind when trying to solve a complex problem using a programming language right from the start. I cannot think of classes, method names, arguments etc. until I get a basic idea of how the given computation should work like on a very high level (and with the low-level details staying "fuzzy"). I know there are people who feel the same way, there was an interesting essay from Paul Graham followed by a very interesting comment on MetaFilter about this: http://www.paulgraham</pre> Jarek Rzeszótko 2012-05-08T16:20:43 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3358 <pre> I think this is probably why (at least in my case), I tend to "think in code" a lot more than "think in natural language" or "think in concepts". like, a person is working with code, so they have this big pile of code in-mind, and see it and think about its behavior, ... because, yes, comments often are a bit sparse. personally though, I think that the overuse of comments to describe what code is doing is kind of pointless, as the person reading the code will generally figure this one out easily enough on their own ("x=i; //assign i to x", yes, I really needed to know this...). comments are then more often useful to provide information about why something is being done, or information about intended behavior or functioning. as well as describing things which "should be" the case, but aren't yet (stuff which is not yet implemented, design problems or bugs, ...). nevermind side-uses for things like: putting in license agreements; putting in documentation comments; embedding commands for var</pre> BGB 2012-05-08T14:21:28 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3357 <pre> On May 8, 2012, at 2:56 AM, Julian Leviston &lt;julian-62HJldmB3ajk1uMJSBkQmQ&lt; at &gt;public.gmane.org&gt; wrote: One of the under appreciated aspects of system like TeX with the ability to do embedded programming, or a system like Self with its Annotations as part of the object, or even python's .__doc__ attributes is that they provide context for the programmer. A large part of the reason that these are under appreciated is that most programs aren't sufficiently well factored to take advantage of these capabilities. As a human description of what the code does and why will invariably take about a paragraph of human text per line of code, a 20 line function requires a pamphlet of documentation to provide sufficient context. Higher order functions, objects, actors, complex messaging topologies, exception handling (and all manner of related nonlocal exits), and the like only compound the context problem as they are "non-obvious". Most of the FP movement is a reaction against "non-obvious" programming. Ideally this</pre> David Goehrig 2012-05-08T14:18:48 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3356 <pre>Sorry it wasn't obvious what I was saying there... They're important because when they're tiny, it's very easy to learn them... Julian On 08/05/2012, at 8:45 PM, Julian Leviston wrote: </pre> Julian Leviston 2012-05-08T13:11:06 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3355 <pre>This is why tiny languages (Alan calls them POLs, I believe: problem-oriented-languages) are so important. A language being anything that involves "communication"... including user interface interaction. Julian On 08/05/2012, at 8:07 PM, Clinton Daniel wrote: </pre> Julian Leviston 2012-05-08T10:45:50 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3354 <pre>Naming poses no problem so long as you define things a bit. :P Humans parsing documents without proper definitions are like coders trying to read programming languages that have no comments (pretty much all the source code I ever read unfortunately) J On 08/05/2012, at 4:36 PM, David Barbour wrote: </pre> Julian Leviston 2012-05-08T06:56:30 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3353 <pre>But I wasn't asking you. :P :) On 08/05/2012, at 4:28 PM, David Barbour wrote: </pre> Julian Leviston 2012-05-08T06:55:23 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3352 <pre> Yeah. I've had trouble with this balance before. We need to acknowledge the path dependence in human understanding. My impression: it's connotation, more than denotation, that interferes with human understanding. "Naming is two-way: a strong name changes the meaning of a thing, and a strong thing changes the meaning of a name." - Harrison Ainsworth (&lt; at &gt;hxa7241) Regards, Dave </pre> David Barbour 2012-05-08T06:36:37 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3351 <pre> I like my PLs to be point free, as much as possible. ;) Regards, Dave </pre> David Barbour 2012-05-08T06:28:15 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3350 <pre>I disagree. We do our best. This is always the case. The problem with language is ... there is no problem. The "problem" is with people and their lack of awareness. I agree that "our best" currently sucks, though. Words aren't the things they refer to - they're just pointers. The only way to precisely use language is to realise that it's not precise, and therefore stipulate DSLs. What's your point? Julian On 08/05/2012, at 4:07 PM, Clinton Daniel wrote: </pre> Julian Leviston 2012-05-08T06:13:32 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3349 <pre>The other side of that coin is burdening users with a bunch of new terms to learn that don't link to existing human concepts and words. "Click to save the document" is easier for a new user to grok than "Flarg to flep the floggle" ;) Seriously though, in the space of programming language design, there is a trade-off in terms of quickly conveying a concept via reusing a term, versus coining a new term to reduce the impedance mismatch that occurs when the concept doesn't have exactly the same properties as an existing term. Clinton On 8 May 2012 00:14, John Pratt &lt;jprattx-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: </pre> Clinton Daniel 2012-05-08T06:07:31 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3348 <pre> I think pretty much every field does this. programmers, doctors, lawyers, engineers, ... all have their own specialized versions of the language, with many terms particular to the domain, and many common-use terms which are used in particular ways with particular definitions which may differ from those of the "common use" of the words. decided not really to go into examples. sometimes, mixed with "tradition" and similar, this can lead to some often rather confusing language-use patterns: constructions involving obscure grammar, words and phrases from different languages (Latin, Italian, French, ...), ... so, programming is by no means unique here. </pre> BGB 2012-05-07T14:48:03 http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/3347 <pre>People do that every day without using a programming language at all. ;-) -Carl -----Original Message----- From: fonc-bounces-uVco7kAcSAQ&lt; at &gt;public.gmane.org [mailto:fonc-bounces-uVco7kAcSAQ&lt; at &gt;public.gmane.org] On Behalf Of John Pratt Sent: Monday, May 07, 2012 10:15 AM To: fonc-uVco7kAcSAQ&lt; at &gt;public.gmane.org Subject: [fonc] The problem with programming languages The problem with programming languages and computers in general is that they hijack existing human concepts and words, usurping them from everyday usage and flattening out their meanings. _______________________________________________ fonc mailing list fonc-uVco7kAcSAQ&lt; at &gt;public.gmane.org http://vpri.org/mailman/listinfo/fonc </pre> Carl Gundel 2012-05-07T14:26:21 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.smalltalk.fonc