720 karma · joined February 15, 2009
In the big picture, visual programming is very natural. It is, in fact,
so natural that we often make flowcharts of how systems work. It would
be better if these flowcharts would actually be the system, rather than
an incomplete, possibly outdated description.
In the details, visual programming is just an inconvenient gimmick.
IMHO. It may change one day.
Not exactly the same, but it reminds me of Smalltalk environments, which
give you a "browser" to view classes, inheritance relationships, etc
etc. while giving you a code editor for the actual method
implementations (example: https://vimeo.com/27850933 ). We use two types of files to program Glow. The detail files, which can
contain anything, and the overview files, which may only contain
constants and how components are connected to each other. An overview
file may not use macros.
Both are editable with any text editor, but the overview file can also
be edited visually as a vectorized flowchart (vectorized to zoom in on
details)
"Both are editable with any text editor" sounds much better (to me with
my admittedly limited experience with Smalltalk) than Smalltalk's
file-less model where everything is a change to the whole system
"image".4. Difficult & lonely life that leads to depression and not achieving anything at all.
That's very insightful. Thanks!
† However it doesn't really pay to customise the basic key bindings away from the defaults too much, because all the major & minor modes have key bindings carefully thought out to be consistent with the defaults.
For example, this chapter: http://david.rothlis.net/emacs/customize_c.html
walks you through this example: What command is run when I press TAB? How do I find out? How do I find its (elisp) source code? How do I find the documentation for built-in elisp functions or macros or "special forms"? All culminating in figuring out (from the elisp source code) which variable you can set to customise your indentation level.
The approach I took in my own guide to learning Emacs[1] was to mention those terms (like "C-x", "buffer", "frame", etc.) as if the reader already knew them, but hyperlinked to a glossary.
The most important part of Sacha's diagram is the bottom left corner: "Learn how to learn more". Every Emacs expert will tell you about "C-h k" and "C-h f" etc, but few novices actually understand how much you should be using those self-documenting features. My guide focuses on this, for those with the patience to work through it. :-)
http://docs.python.org/2/library/ast.html
http://golang.org/pkg/go/parser/
(See also gofmt: http://golang.org/cmd/gofmt/
and gofix: http://golang.org/cmd/fix/ )Mozilla's talk about testing FirefoxOS, at the Google Test Automation Conference last week: http://www.youtube.com/watch?v=X41eqcmC2Dk
Writeup: http://lwn.net/SubscriberLink/548910/9c5d6bd1bd69f34c/
Demo of automated UI test using Appium to test an app on the FirefoxOS simulator: http://www.youtube.com/watch?v=1J0aXDbjiUE#t=34m30s
YouView is looking for Test Automation developers. You'll be writing test scripts and working on our test infrastructure, much of which we open-source (e.g. http://stb-tester.com ).
We use a lot of shell & python, and a bit of C; but intelligence, the right attitude to automation (automate everything!), programming ability, and a focus on simple solutions are more important than experience with specific technologies. You could learn a lot about Unix here. Might also suit an experienced Linux sysadmin (with excellent shell scripting) looking to do more python programming.
Not forever:
http://www.macrumors.com/2009/12/24/apples-research-on-tacti...
http://www.macstories.net/news/apple-patents-keyboard-with-a...
Maybe what I don't understand is all the effort people put into making pretty themes for their editors --there are millions of these themes out there-- and almost all of them insist on highlighting (drawing attention to) the language's keywords of all things. The least important part of any program.
It would also be interesting to compare with code with decent syntax highlighting. For some reason I don't quite understand, most syntax highlighting out there highlights the wrong thing: keywords. It needs to highlight the site-of-definition of functions, variables, etc. For example: http://david.rothlis.net/code_presentation/distracting_synta...
When some people say "Modern C++" they mean template meta-programming (traits, partial template specialisation, etc) as exemplified by Alexandrescu's book "Modern C++ design": http://www.amazon.com/Modern-Design-Generic-Programming-Patt... (note that I am not necessarily advocating such techniques, but understanding them will certainly help when you run across them in the wild).
Random testimonial: «The guide has been extremely helpful and without it, I wouldn't be making the switch from vim. I particularly like that you present just enough information about various tools that I can use them productively, while referring to the excellent built-in docs. A lot of the programmer-critical tools have good documentation, but no "here's the bare minimum you need to know not to go back to your more comfortable environment" guides.»