How is this any helpful? Are they supposed to implement everything in terraform or similar, is that your suggestion? Why don't you completely remove the editable UI then, if whoever is using it is doing it wrong. What a typical arrogant and out of touch with customers Google response.
There is rarely a situation where you can't slip a printf or log message into a piece of code and observe how it's working in production. Depending on the complexity of the problem the debugger can also hide a lot of problems- is there a timing issue? is it intermittent? What happened the last 200k times? An interactive debugger technique doesn't help you at all if all you have is a coredump of an issue that happens once a month.
It is definitely a personal preference, but I just find myself in too many situations where the constraints to make a debugger in a dev environment work well end up adding a lot of complexity to the problem space. I know printf/write to a file works every time, everywhere.
I use both. They are useful in different situations. printf is lightweight, and can let you dump a lot of information very fast. It's a good approach when you're reasonably confident about what you need to know. A debugger gives you more flexibility about the questions you can ask on any particular run.
Language and environment independent. It just works. It's like IDEs -- so many people spend so much time writing and learning IDEs specific to a language rather than just picking a standard text editor that can be used for any language on any platform.
Well, he/she isn't saying anything about smalltalk, but talking about python. Are you sure these two pose the same problems when it comes to automated refactoring? Apart from just lack of static typing, these languages could be miles apart when it comes to how dynamic they are and what problems this poses to automated refactoring. For example, the fact that attribute access in python can be delegated to a function that will receive the attribute name as an argument and decide whether that object has this attribute or not and what it is, or the fact that you can dynamically generate a new class whose attribute names and implementation come from outside as function arguments. How would you deal with automating the renaming of such an attribute when it is defined and used across wildly varying circumstances. I have no idea if smalltalk can do this, or even if my examples are good examples of showcasing the automated refactoring problem, but just raising a point.
> if my examples are good examples of showcasing the automated refactoring problem
They're not.
More to the point: Smalltalk is as dynamic a language as practically possible and was like that for two decades before Python existed. The `__getattr__` from Python, `method_missing` from Ruby, and `__index` from Lua are all inspired by Smalltalk's `doesNotUnderstand`. The concepts of metaclasses and first-class message sends was invented in Smalltalk. The idea of inspecting code using a GUI instead of flat text files also originates with Smalltalk. Refactoring, as noted by GP, also came out of Smalltalk-land. Smalltalk gives you all that without any static typing in sight.
How? Smalltalk is special. Normally, you have your code: a static blueprint of what's going to happen; and a program: part of computer memory which your code gets loaded into and gets executed. This is true for both statically and dynamically typed languages: the familiar type something -> hit "Run" -> see if it worked cycle works equally well in Java and in Python.
Smalltalk is not like this. With Smalltalk, all you have is a program. It's always running. You hand it the code and it patches itself dynamically in memory. The classes are live objects you can query. Metaclasses are, too, objects you can query. They implement methods for refactoring. It's easy, because there's no need for any parsing, statical analysis of any kind: you just iterate over all the classes in your system and ask them one by one: "do you call such-and-such method?" And the classes inspect themselves and say: "why, yes, I call it when handling such-and-such messages, here's the list".
Really, Smalltalk is special. It's not unique: Forth and Common Lisp come to mind, Self, Lua and Io too. But it's special and very few modern languages come close to its capabilities.
Not if you were Richard Feynman. That is sort of the point of the article. Can or should more people be able to do this? Amusingly, Rob Pike claims some of the best programming advice he ever got was from Ken Thompson. The advice amounted to: when you are stuck, stop, think hard, and then fix the problem.
This advice could be seen as amusing rhetoric to stop and think more often.
Today more than ever I witness people, professionals even, that just keep on hopefully poking and prodding back and forth in some grandiose effort to maybe just somehow break things back up into working order, which makes me very sad because all that is required is to step back, relax, and just genuinely look at things with your mind.
In that situation I'm always reminded of Feynman's "He fixes radios by thinking!", and that, if anything, we should teach people how to think instead of shovelling massive amounts of pre-baked recipes into their head.
> And all the time, on the way to his house, he's saying things like, "Do you know anything about radios? How do you know about radios-you're just a little boy!"
> I start walking back and forth, thinking, and I realize that one way it can happen is that [so and so...]
> So the guy says, "What are you doing? You come to fix the radio, but you're only walking back and forth!"
> I say, "I'm thinking!" Then I said to myself, "All right, take the tubes out, and reverse the order [because so and so...]
> So I changed the tubes around, stepped to the front of the radio, turned the thing on, and it's as quiet as a lamb: it waits until it heats up, and then plays perfectly-no noise.
> He got me other jobs, and kept telling everybody what a tremendous genius I was, saying, "He fixes radios by thinking!"
> The whole idea of thinking, to fix a radio - a little boy stops and thinks, and figures out how to do it-he never thought that was possible.
This is something we try to instill in our new ops people. If you don't understand what's going on, don't do anything. There's nothing to be gained by quickly applying the wrong solution.
In a world where organisations want everything to be a "process", and broken down into tiny steps, it's useful reassurance that retreating to a darkened room (or whatever your preferred environment might be) and thinking through a problem is a valid strategy.
The way software development is mostly done these days, it's about writing the solution as the first and only step. It helps being reminded that clearly stating what the problem is and then taking a bit of time thinking about it is important.
I was very interested in the subject, but hated this video.
Very superficial, started off with a complicated relational schema to criticize relational databases, but never ended up explaining how a graph database would simplify the problem. I thought that the graph database concepts + language was way more complex than SQL schema + language.
Very fast talking and moving of slides, is this supposed to sound or look smart? On top of that, 50% of the time the video was a close up to the presenter's face moving left and right in an awkward fashion.
Good feedback. I might need similar feedback for my upcoming talk. I am about to give a talk about Cayley (open source graph db written in Go) and I am working on my slides
http://oren.github.io/adventure-graphs
Let me know what you think and also join us on IRC (#cayley on freenode) if you find it interesting.
TL;DR: graphs are everywhere in the real world, so using a graph DB will be simpler and more efficient; examples of graph queries follow.
Thank you but may I ask who this presentation is for? Because from a quick glance, it's not very deep in technical details. I mean I'm curious about graph databases, but comparing them to vanilla SQL schemas isn't very informative. What I really want to know is what makes them different from denormalized schemas (which is what I expect most people would use).
"First of all, I want to thank the members of the Vineyard Christian Fellowship Church in Champaign, Illinois for everything that you have done to help me and my family in our times of crisis. It's been a long time since I've seen or heard from any of you, but I think about you always. You have been such a blessing to me, my wife, and Daniel, and I could never thank you enough for showing us Christ's love when we needed it most. I thank God every time I think of you - I thank Him for bringing you all to us in our deepest times of need. Even out in the middle of Illinois with no friends of family, God showed that He was still watching after us. Thank you for being His hands on Earth. Specifically, I'd like to thank Joe and Rhonda, Pam and Dell, and Herschel and Vicki. There were many, many others, too - so many people helped us that it would be impossible to list them all."
How dare he thank the community that supported him in time of need and where he feels welcome and at home!
Snark aside, some of the most amazing thinkers humanity ever produced were pretty damn insane (Newton, for example, was quite bonkers). As Geoffrey B. West said: cities last while companies die in the long run, because cities tolerate crazy people and companies don't. I highly doubt you risk going insane because the author of a book on programming is an openly devout Christian. AFAIK, Knuth's works weren't considered brain damaging either.
I prefer people who are accepting of other's perceived faults. Take you, for example. You are obviously a bigoted asshole, but that doesn't mean that you might not have some decent programming skills or that we don't have anything in common.
