However, I'm also less and less convinced that the one really killer feature that Lisp allows, macros, really makes up for the downsides of the s-expr syntax.
Sorry, what is the downside?
(foo x) vs. foo(x) doesn't make a difference to me.
Is this an implied downside that amounts to not having used the language very much?
There are two downsides. First, lisp syntax requires a lot more parentheses because every expression must be parenthesized. Infix languages eliminate most of these. Admittedly this also occasionally introduces some problems with operator precedence but in practice these aren't that big of a deal. S-expr syntax just isn't as readable.
Second, prefix notation is terrible for complex arithmetic. Even the most ardent admirers of s-expr syntax will concede this.
I certainly haven't done as much lisp hacking as some people but I've written a complete html-mail archiver:
http://github.com/cageface/macho
They eliminate some of them, mostly ones associated with math. The rest of them they replace with different types of parenthesis.
Brackets, braces, tabbing and carriage returns, semicolons. They are all structure delimiters. In lisp you have one structure delimiter "()", in non-lisps you have many.
I don't see how it is terrible for complex arithmetic. Lisp order of operations is explicit. Code does not become more clear because you add a bunch of implicitly defined structure, (no matter how much you were drilled in math school, it is still another thing to remember). Besides, what makes math different from anything else? I end up parenthesizing infix math anyway, simply because it is hard to keep track of the order of operations.
You are certainly entitled to your opinion, and I didn't meant to imply that you aren't, I was just interested in your reasoning.
To me, 'readability' is a vacuous claim, being that they only thing that 'readability' really means is 'what I am used to'. (I write lisp code for a living, am used to lisp code (lisp was my first language), and I find it much easier to decipher than other languages).
The great thing about using a variety of different structure delimiters instead of one is that they delimit different kinds of structure and make those delimitations more clear and explicit. Real Lisp code makes liberal use of redundant whitespace to indicate structure for similar reasons. In fact, a lot of Lispers will tell you they don't even see the parentheses after a while. If this is really so, why not just eliminate them and use Python instead? You lose macros but gain a lot of syntactic clarity.
As for arithmetic, most people will find this:
(/ (+ (- b) (sqrt (- (* b b) (* 4 a c))))
(* 2 a))
less readable than this:
(-b + sqrt(b * b - 4 * a * c)) / 2 *a
It may be that readability is relative but those that find prefix notation more readable in general have been in the minority since Lisp was first invented.
you could, but then you would be needlessly breaking the regularity of the language. the whole point of lisp is to make stuff super ultra regular so that it is really really easy to manipulate unambiguously.
I'm not saying he's better than Charlie, but I find it easier anthropomorphizing a (brilliant!) action figure. (Not only is he great at debugging code, he's also pretty darn creative).
The first thing to point out is that writing software doesn't map very well onto civil engineering. In civil, your base requirements are supposed to be very well defined. 'I need a bridge from point a to point b, it has to support x amount of traffic weighing y kilos'.
The point of the Tacoma Narrows incident is that 'flutter' was something that was hereto unmentioned in the design requirements of the bridge. It wasn't accounted for, therefore the bridge collapsed. To imply that 'proper engineering' would have prevented the collapse is wrong. They used proper engineering... they just didn't account for everything that they needed to account for.
No one is going to argue that solid design, trusted components, testing and QA are not important parts of programming. (They are good, especially the components, testing, and QA bits).
What the original Spolsky 'duct tape programmer' post is railing against is the disguise of over-engineering (because of incompetence) as the above things (particularly the design part).
The point being that the extremely competent don't need to disguise their software in an elaborate drapery of buzzwords and patterns. (Because they don't need a justification to fall back on if it doesnt... 'well we used x and y and z hot new thing').
I majored in a traditional engineering, and I wish programmers/CS types would stop comparing programming with mechanical/civil engineering; they are completely different processes with completely different mentalities due to completely different requirements.
Which is not to say there isn't some overlap - writing software for, say, a MRI machine would likely be held to the same processes and standards as most traditional engineering, but let's be honest, 99% of programming isn't that.
> "The standard approach taken to minimise or prevent these unacceptable outcomes is conservative design, using trusted components, with testing and quality assurance being critical parts of the design and implementation processes."
I think the blog author is out of his expertise here - this is an extremely "software" abstraction of the engineering design process.
I'm not convinced the traditional engineering process works at all in software - traditional engineering is waterfall (where do you think it came from?), but unlike a bridge you rarely ever know all of your requirements and specifications up front. Also, you design 100% of a bridge up-front because you can't "iterate" a bridge, but you sure as hell can iterate a website.
We push code out quickly and iterate because we can, and the consequences for system failure are minimal at best. Want to try a new lane arrangement on a bridge? If you could build bridges like you build software, you'd just build two with the competing lane designs, and get half of the car traffic to drive over each. Oh wait, you can't do that in real life. This is why I balk every time someone thinks we should be held to the same standards as traditional engineers - there's no compelling gain and everything to lose.
> Want to try a new lane arrangement on a bridge? If you could build bridges like you build software, you'd just build two with the competing lane designs, and get half of the car traffic to drive over each. Oh wait, you can't do that in real life.
Nope. You can, however, run rather detailed mathematical simulations of what the varying loads will do to the bridge and cross-check against established data.
Want to know the _real_ difference between civil engineering and software engineering?
Yes, this is what civil engineers do, but it's a highly suboptimal alternative to real data, which is impossible to collect due to cost and the laws of physics.
If for $200 civil engineers could test a new bridge design against real, live traffic, with no risk of injury or loss of life... you bet your ass they'd be doing it. But that's not going to happen, because we can't will multiple bridges into existence for almost no money, nor can they occupy the same space :)
This is also why transit planning is often such a clusterfuck - the mathematical models behind urban growth, commute patterns, etc, are often poor predictors of what will actually happen. We've got road layout down to a pretty precise science, but that's about the limit of it. The impact of said roads and thoroughfares on the communities surrounding it, for example, are still poorly understood.
Roundabout way of saying it: I just don't think civil engineering and software engineering will ever truly be comparable. The amount of consequence-free testing, combined with the ability to iterate for extremely cheaply, will never be matched by a field that must build expensive physical objects.
Actually I rather enjoyed the article, especially the opening bit about the pursuit of popularity destroying blog value, but you can't just pretend that software engineering is just simply a form of engineering still in its dark ages (though it's obviously cruder than traditional engineering disciplines). Computer science is an extension of pure math going back thousands of years, of which civil engineering is another only slightly older offshoot. The problem spaces are simply not comparable.
In civil engineering you are dealing the same constraints: physics, which can be refined to perfection because they will be used billions upon billions of times throughout history and will never change. In civil engineering the stakes are high, people will lose lives. Finally, the parameters for success are very easy to measure in advance... it's easy to calculate how much traffic a bridge will carry, and you can even render exactly what it will look like for aesthetic evaluation before construction begins at all.
Contrast with software where the problem space is infinitely larger (ie. the entire realm of abstract thought vs physical space, which also makes it less intuitive by people btw). The costs of failure and repair are most often trivial (especially for web software). And the suitability of software is often not known at all until it is delivered (in this regard architecture has more in common with software engineering). You can't just hand-wave these things away by stating that software engineering is an immature discipline. Even with the exact same number of man hours behind software engineering that you have behind civil engineering, there would still be a such a tiny dent in the problem space as to leave software engineering looking primitive.
It's not that no one takes software engineering seriously either, take military or NASA software. Those guys have the most advanced software engineering principles on the planet, but even there, it's specifically suited to their use case. I'm sure there's a lot we could all learn from them, but if you want Microsoft Word to have that quality are you prepared to pay $500,000 a head to run it?
I agree that Joel totally threw the baby out with the bathwater in the duct-tape programmer defense, but let's not disparage the state of software engineering. It's certainly much less disciplined than other forms of engineering, but that's simply a cost-benefit tradeoff that seems reasonably close to optimal.
>In civil engineering the stakes are high, people will lose lives.
If you're building a bridge, yes. But it's not always so critical.
This holds in software engineering as well - If you're mucking about writing the next tetris, odds are, noone's going to die if you stuff it up. If you're writing embedded code in a medical device, lives definitely are at risk (and if you step back and look, not only is embedded code the majority of deployed code out there, but it also has some of the most mature development practices - not everything in software is agile)
The problem arises when you try to draw the line between those two extremes - for example, who knew people were daft enough to follow GPS instructions that navigated them under bridges that were obviously too law, or off piers into harbours, or into oncoming traffic on one-way streets or onto train tracks (complete with oncoming trains). The criticality of the system you're developing isn't always a simple thing to determine.
And don't forget - history has recorded very very similar arguments to yours that claim exactly what you're claiming, while arguing that mechanical engineering will never go from art to science...
You give an excellent example of the scoping issue:
Someone can write a computer program that will run detailed mathematical models of a bridge and cross-check against established data. I can also write a program to simulate flutter, run simulations of car engines, the power grid, the stock market (You can program almost anything imaginable).
I challenge you to write a program that will run a detailed mathematical model of a computer program and cross checks against established data gleaned from other programs. Even if you did, it wouldn't be terribly useful as it would just tell you that the program runs in such and such a way; you'd still not know if it actually does what it is supposed to do. Does it fit the problem domain, or is there some 'flutter' that you didn't know about?
A lot of the improvements in reliability of engineering disciplines of the last 50 years have been because of the ability to simulate things better... mostly by use of the computer.
There are therefore two types of error in a piece of software:
1. 'Stupid' error (I used the wrong units or I used the wrong function).
2. Thought error (I didn't understand the problem or I goofed in my reasoning about it).
I'd argue, therefore, that the 'stupid' errors are the errors that can be solved by software engineering.
(Using higher level languages, better compilers, better type systems, etc.) The issue being that there is only so much that you can actually do to solve them with software.
The second set is a bit more difficult. Am I going to validate my bridge simulator by using a different bridge simulator? Sometimes we certainly do do this, and this is kind of the basis of iterative development (if each version of a program is a different program). At some point, I will need to understand Civil Engineering as well as Software Development to get my program to function as a Civil engineer would expect it to.
This would imply, that at least in some domains, software engineering is the equivalent of meta-engineering. (I am programming the set of rules used by civil engineers).
It gets more difficult the further away from engineering/scientific disciplines you get.
What exactly would be the discipline be behind web programming or writing an HTTP server?
Where can I get my thought guidelines to understand how I should think about the different problems?
I'm sure that there is progress to be made in software engineering, but I'd guess the progress won't come from looking at engineering disciplines, and I'm pretty sure it is wrong to say that the only difference is timeframe.
> I challenge you to write a program that will run a detailed mathematical model of a computer program...
Model checking is well-established in hardware design and is making headway into software. Model checkers can verify high-level properties. For example, I am currently working on a p2p gossip algorithm. I use a probabilistic model checker to verify that the peer selection service provided by this algorithm fulfils its contract - in the steady state selected peers are uniformly distributed over the members of the network. I use a model checker because the maths involved is sufficiently complicated that I don't trust either my theoretical results or that the code matches the mathematical model I am working with.
"Another telltale sign is that instead of going directly to web pages, they use the search bar."
I've seen this as a 'test' for the unsophisticated user a couple of times, and I don't understand the reasoning behind it.
I do almost all of my web navigation via search-bar and auto-complete.
It works quite well (this particular Facebook page is weird though).
This is mostly because I don't like managing bookmarks (Bookmarks get too cluttery if you actually use them as bookmarks... I only use them for temporary stuff like saving pages for a product i'm researching).
If I really want to find something and I can't remember the name of the site (which is a rarity), I'd just use browser history or search for keywords anyway...
I think that there is something ergonomically wrong with the way that we name websites. https://hackertimes.com/ does not stick in my head (it does not come to mind first anyway). "Hacker News" totally does, and it is easier to type.
I think that implying people are unsophisticated when they are really just lazy/apathetic about specific technical details leads you to the wrong conclusions about what type of things they can handle.
I think you have a good point about the test not being perfect. But I think your explanation is a great example of what such basic tests are really trying to get at: people's usage habits reflect their level of knowledge. I agree that the reasons you bring up are valid, and to use the search bar for those reasons shows your grasp of the technology. There are pleny of people who use the search bar instead of the address bar because they just plain don't understand the address bar. Their reasons are the complete polar opposite of yours, but the end result is the same or very similar usage pattern. Unfortunately, like so much in life, it takes a lot more than a simple test to accurately determine the "why" behind an action instead of just measuring the "what."
Here is a long, only tangentially related story about the computer usage habits of "normals" where the action, a system restart, is much less an indicator of the problem than the reason...
I was getting together with a bunch of high school friends after our first year of college. We were chatting about our experiences, and as tended to happen around myself and my computer savy friend, discussion of computer problems started. One person began sharing a problem that they have with their laptop where for some reason the keyboard "gets messed up" and numbers start appearing instead of letters. I thought it was amusing, until I was shocked to hear not one but three more people jump in and share that they've had the same strange problem. These weren't dumb people either, just not tech savy folks. I was about to explain the concept of numlock to them, when one of the people pointed out that the problem could be fixed with a reboot, and advised the others to try it the next time they encountered the issue.
As I said, not stupid people. Most of them were at ivy league institutions and have gone on to successful careers. They don't know jack about computers. These are the "normals" we have to make sure not to forget when we design software.
I think that the idea that Amazon is selling hardware is missing the point entirely. A lot of the time companies lose money selling hardware (ex. the price to produce a PC is more than the selling price... they make up for it by being paid to put 'trial' software on the windows install).
So, in parallel, amazon doesn't really give a crap about whether they sell a ton of kindles. What they care about is that the amazon kindle store makes a crap-ton of money. If everyone goes out and buys an ipad, and "kindle on ipad" is a killer app for ipad, amazon ends up making way more money than they would trying to match their own hardware against Apple's.
I'm an avid reader and I got the DX when it came out (it is freaking sweet). I'd probably be too distracted/eye-strained reading on a tablet PC for the number of hours that I do. (I realize that I am an outlier, however).
My one complaint is that there are actually a lot of books that I cannot get for the kindle, and it is hard to take notes in the margin so I end up reading certain books on dead trees. (Maybe the ipad touch screen will make it easier to do margin notes?)
Amazon looses if backlit screens beat the kindle and other e-ink screens. People don't read voluminous quantities on a backlit screen; it's hard on the eyes. Amazon will sell more books if the main platform has an e-ink screen, because people will read less if they are using a backlit screen- imho. (this is if we hold the user base constant across devices)
It's true, it's not a total loss if the iPad dominates yet the kindle app is popular, but it's not the ideal scenario.
Isn't this the same philosophy people had about the video games industry for a long time?
It's proven that "hardcore" gamers buy a lot more games than casual gamers, and that they are far easier to sell related merchandise and subscription to.
Yet, the success of the Wii has proven that the sheer size of the casual demographic more than makes up for the fact that they buy fewer of your products.
There will always be the hardcore, voracious readers, but I'm not convinced that it's not worthwhile to go after the casual readers who might only read 2-3 books in a whole year.
People who get the kindle are more likely to read a lot, whereas people who get the ipad (as opposed to the kindle) are more likely to read fairly casually. (You get the ipad because you want the internet and all of the games/apps).
I'm not really sure that it holds that people will read less on their backlit device than on a normal kindle. I'm a software developer and I spend all day staring at a computer screen (8+ hours). I take periodic breaks, and yes, it is bad on my eyes, but the back-lighting of the screen isn't enough to stop me from doing it (I only really notice at my yearly optometrist appointment).
If the iPad app allowed you to pick some mellower colors for the text/background, that would probably go a long way towards making the device usable. Black on Grey (or dkgreen on black!) is a lot easier to look at prolonged than black on white, for example.
For me, the more obvious benefit to reading on my Kindle isn't lack of eye strain (I stare at monitors all day too), but lack of glare. Even with full backlight, using my laptop outside on a sunny day ranges from being uncomfortable to completely unusable. With the e-ink screen, that's barely an issue.
Sorry, what is the downside? (foo x) vs. foo(x) doesn't make a difference to me.
Is this an implied downside that amounts to not having used the language very much?