31–40 of 66 posts
His book a philosophy of software design is an excellent read.
Link: https://www.amazon.com/Philosophy-Software-Design-John-Ouste... Looks like it was just released!
>Programmers tend to worry too much and too soon about performance. Many college-level Computer Science classes focus on fancy algorithms to improve performance, but in real life performance rarely matters . Stopped reading there. A great plague of modern software development is a complete disregard for performance or resource conservation.
The problem is not this advice, but that people tend to stop reading (or remembering) there. It's misapplied or misunderstood so often that I wonder if it shouldn't be promulgated. Today something like this may be more appropriate: "You should pay attention to performance, but your algorithms probably won't be the problem. It's more likely you're doing something stupid or wasteful, probably with the help of your tech…
That's EXACTLY my problem whenever I hear this or similar advice. It's exactly what I think when I hear people (mis)quote Knuth by mindlessly parroting the old adage (optimization is the root of all evil). Too many people interpret this as a licence to waste resources and bloat your program with reckless abandon to an egregious degree, that I too think people should probably not say spread stuff like this.
Earlier quoted context omitted.
TCL is a great systems programming language. When I need a glue language for an imperative model program it's my first choice.
What Lua is doing today, TCL was doing 20 years ago. Though I believe Lua is a smaller binary, which matters in some embedded scenarios. According to [1], the core Lua interpreter is 40kB with additional base libraries of 22kB, so total of 62kB. There are a variety of "small TCL" implementations [2], and one of them, TinyTCL claims to be excluding C library functions. I can say that for my embedded requirements, Lua…
This is for full featured *nix systems programming in the HPC world so ymmv.
Side note: Ousterhout was famous for being the author of Tcl/Tk, which was a popular language and GUI toolkit in the early days of Linux (before Qt and GTK came along). I wouldn't be surprised if many older Unixes are still running Tcl/Tk apps.
Earlier quoted context omitted.
What Lua is doing today, TCL was doing 20 years ago. Though I believe Lua is a smaller binary, which matters in some embedded scenarios. According to [1], the core Lua interpreter is 40kB with additional base libraries of 22kB, so total of 62kB. There are a variety of "small TCL" implementations [2], and one of them, TinyTCL claims to be excluding C library functions. I can say that for my embedded requirements, Lua…
Interesting. I tried Lua about 6 years ago and found myself unable to see an upside to the language in comparative perspective with python and tcl. This is for full featured *nix systems programming in the HPC world so ymmv.
I indeed don't see it having any benefit over Python or TCL in more sophisticated environments.
Earlier quoted context omitted.
Link: https://www.amazon.com/Philosophy-Software-Design-John-Ouste... Looks like it was just released!
Salvatore 'antirez' seems to think pretty highly of the book too; got a copy on his recommendation and am just starting to read it.
http://antirez.com/articoli/tclmisunderstood.html
(Ousterhout is the creator of Tcl and both antirez and Richard Hipp of sqlite are Tcl programmers)
The three most powerful words for building credibility are "I don't know" I had a supervisor once who always had an answer to your question. He was always 100% sure he was right. He was not always right. Consequently, going to him for help would sometimes result in the problem becoming worse. The best supervisor I ever had was the one who routinely told me "I don't know, let me call {PersonInOtherDepartment}" or "See…
So, say what you think but at the same time ask (demand?) an argument or discussion.
A friend has a T-shirt with the words: Always sure, often wrong.
Also see: https://www.psychologytoday.com/us/blog/work-matters/201002/...
Except when speed is part of the definition of working. For example deep learning. The correct implementation was not enough until the hardware was fast enough.
>Programmers tend to worry too much and too soon about performance. Many college-level Computer Science classes focus on fancy algorithms to improve performance, but in real life performance rarely matters . Stopped reading there. A great plague of modern software development is a complete disregard for performance or resource conservation.