Slashdot Mirror
Toward Better Programming
An anonymous reader writes "Chris Granger, creator of the flexible, open source LightTable IDE, has written a thoughtful article about the nature of programming. For years, he's been trying to answer the question: What's wrong with programming? After working on his own IDE and discussing it with hundreds of other developers, here are his thoughts: 'If you look at much of the advances that have made it to the mainstream over the past 50 years, it turns out they largely increased our efficiency without really changing the act of programming. I think the reason why is something I hinted at in the very beginning of this post: it's all been reactionary and as a result we tend to only apply tactical fixes. As a matter of fact, almost every step we've taken fits cleanly into one of these buckets. We've made things better but we keep reaching local maxima because we assume that these things can somehow be addressed independently. ... The other day, I came to the conclusion that the act of writing software is actually antagonistic all on its own. Arcane languages, cryptic errors, mostly missing (or at best, scattered) documentation — it's like someone is deliberately trying to screw with you, sitting in some Truman Show-like control room pointing and laughing behind the scenes. At some level, it's masochistic, but we do it because it gives us an incredible opportunity to shape our world.'"
In my 25 years of professional programming experience, I've noticed that most often, most programming problems are caused by improper implementations of the separation of unrelated concerns, and coupling of related concerns. Orthogonality is difficult to achieve in many programming exercises, especially regarding cross-cutting concerns, and sometimes the "right" way to code something is tedious and unusable, involving passing state down through several layers of method parameters.
Or.....
Maybe software development is just hard and you need to be a rocket scientist to see it.
Something something blames his tools.
... I'm firing up Emacs right now to solve it.
Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
You think programming's bad? Think about electronics, especially analogue electronics.
Incomplete, inaccurate data sheets. Unlabeled diagrams (where's the electronics equivalent of the humble slashed single line comment?), with unknown parts given, and parts replaced with similarly numbered replacements with subtly different qualities. And then you've got manufacturing variances on top of that. Puzzling, disturbing, irreproducible, invisible failure modes of discrete components.
You think linguists haven't pondered the same challenges for millenia? Chomsky famously declared that language acquisition was a "black box." There is no documentation. Syntax, semantics and grammar get redefined pretty much all the time without so much as a heads-up.
And the result of all this? We wouldn't have it any other way. Programming will be much the same: constantly evolving in response to local needs.
...wear a fucking helmet.
The post essentially points in the direction of the various failed 4GL attempts of yore. Programming in complex symbolism to make things "easy" is essentially giving visual basic to someone without the knowledge enough to avoid O(n^2) algorithms.
Programming isn't hard because we made it so, it's hard because it is *intrinsically* hard. No amount of training wheels is going to make complex programming significantly easier.
A computer could do it for you.
Better tools and languages just allow bad programmers to create more bad code.
http://michaelsmith.id.au
I see the problem as more of a chase of new stuff all the time, in an attempt to be more productive.
Whilst there's a certain element of progress in languages, I don't see that it is necessarily enough better overall to be worth the trouble - yet we have new languages and frameworks popping up all the time. Nobody becomes an expert anymore, and I think that because programming is hard, a lot of people get disillusioned with what they have and listen to the hype surrounding a new technology (that "is so much easier") and jump on the badwagon... until they realise that too is not easy after all, and jump onto the next one... and never actually sit down and do the boring hard work required to become good. Something they could have done if they'd stuck with the original technology.
Of course no-one sticks with the original, as the careers market is also chasing the latest tech wagon because they're partly sold on the ideas or productivity, or tooling or their staff are chasing it.
Its not just languages, but the systems design that's suffered too. Today you see people chasing buzzwords like SOLID, unit-testing using shitty tools that require artificial coding practices, rather than do the hard, boring work of thinking what you need and implementing a mature design that solves the problem.
For example. I know how to do network programming in C. Its easy, but its easy to me because I spent the time to understand it. Today I might use a WCF service in C# instead, code generated from a wizard. Its just as easy, but I know which one works better, more flexibly, faster and efficiently. And I know what to fix if I get it wrong... something that is impossible in the nastily complicated black box that is WCF sometimes.
But of course, WCF is so last year's technology.. all the cool kids are coding their services in node.js today, and I'm sure they'll find out its no silver bullet to the fundamental problems of programming just being hard and requiring expertise.
What is programming?
The answers I got to this were truly disheartening. Not once did I hear that programming is “solving problems."
I'd like to think that's because the majority of programmers (not once? Does that mean all of us?) aren't the sort to bullshit you with CEO-level bullshit about vision and buzzwords that fit into powerpoint slides.
It's probably not true, but it's a nice dream.
The problem with defining programming as "solving problems" is that it's too vague. Too high level. You can't even see the code when you're that high up. Hitting nails with hammers could be problem solving. Shooting people could be problem solving. Thinking about existential crisis could be problem solving.
The three buckets:
Programming is unobservable - you don't know what something is really going to do.
Programming is indirect - code deals with abstractions.
Programming is incidentally complex - the tools are a bitch
Something something, he doesn't like piecemeal libraries abstracting things. "Excel is programming". Culture something.
The best path forward for empowering people is to get computation to the point where it is ready for the masses.
We're there dude. We've got more computational power than we know what to do with.
Cue "that's not what I meant by 'power'".
What would it be like if the only prerequisite for getting a computer to do stuff was figuring out a rough solution to your problem?
Yep, he's drifting away into a zen-like state where the metaphor is taking over. Huston to Chris, please attempt a re-entry.
AAAAAAAAnd, it's a salespitch:
Great, now what?
We find a foundation that addresses these issues! No problem, right? In my talk at Strange Loop I showed a very early prototype of Aurora, the solution we've been working on to what I've brought up here.
My experience is that programmers are over 90+% *libertarian*.
A pox on social conservatives and fiscal liberals both.
Typically no two software engineers agree on a solution.
Business introduces additional constraints and decisions.
Younger folks want to reinvent the wheel.
Etc.
If only there was a way to take a real life need or want and make the machine do it. Oh wait, that's called programming. Well, what if I want to use only human language to describe what I want? Well, there's a solution for that too. Hire a programmer.
Not clear to me that his is a viable objective. 80% of the masses do not think like programmers. Some might be trainable. Some, not so much. Many will not want to think the way problem-solving in code requires. I'm not sure how to quantify it, but the amount of effort expended on a project like this may not see an appropriate payback.
Even if we change the environment and act of "coding", the problem-solving itself still requires clear thinking and it *probably* always will.
If the Government becomes a lawbreaker, it breeds contempt for law;
This.
So, talking to a pair of liberal arts professors about nature versus nurture in gender differences, I finally got to the question:
"What percent do you believe is from nurture, and what percent do you believe is from nature?"
The answer?
"100% from both."
When someone has a mindset that can't grok the idea of fractions of a whole, there's no reason why we should expect that they can construct even the most basic computer program. This is like the manager who wants to maximize on quality, minimize on resources, and minimize on time, all simultaneously. You can have cognitive dissonance in your brain all you like, but the real world isn't as forgiving.
Programming is hard because we only call it programming when it's hard enough that only programmers can do it. Scientists do stuff in Mathematica, MBAs in Excel, or designers in Flash/HTML, that would have been considered serious programming work 30 years ago. The tools advanced so that stuff is easy, and nobody calls it programming now.
Lots of stuff that takes real programmers now will, in 20 years, likely be done by equivalents of Watson. And the real programmers will still be wondering why is so hard.
I knew it! It's Bush's Fault!
I hear the California government has a bill to rename the San Andreas Fault to "Bush's Fault", just so they never have to stop using the phrase! But that may be just a rumor ...
Socialism: a lie told by totalitarians and believed by fools.
...fits into the picture somewhere.
As long as we continue to have so many languages, architectures, components and designs floating around we're turning the programming problem space into a hyperdimensional clusterfuck. We don't even care to make programming easy for programmers so we stand no-hope-in-hell chance making it work for Joe.
Like setting loose electricians in a spaghetti rats-nest of cables, or cleaners aloft the worlds landfill sites. Sometimes the best option is to get a dump truck and start over, but I guess that's how we got into this mess in the first place...by starting over, over and over again.
You can't fix this. We're all just committed to keep cleaning our cubicles as far as we can and that's the best we can do.
Some interesting points in the article. I think there's nothing really stopping you from creating a high-level representation that lets you work abstractly. A graphical programming model is probably going to be too simplistic, but the card example could easily be something like Cards.AceOfSpades. Or being able to call something like Math.eval(<insert some math here>).
Where it falls apart is when you have to hook this up to code that other people have written. If there was a single PlayingCard library that everyone could agree on, you might be able to create a card game by adding a "simple" set of rules (in reality, even simple games tend to have a lot of edge cases, but this would at least free up the nitty gritty work to allow writing something more like a flowchart expressing the various states).
Unfortunately, it's unlikely that a single library is going to meet everyone's needs. Even if you manage to get everyone to stick to one framework, e.g. if all Ruby developers use Rails -- as soon as you start adding libraries to extend it you're bound to end up with different approaches to solving similar problems, and the libraries that use those libraries will each take a different approach.
I used only free software programming for about 10 years and I thought I was pretty efficient at writing code. However, no matter what there where always poor documentation to deal with and strange bugs to track down where libraries just didn't work right.
Once I returned to school I started using MATLAB for some engineering classes and overall I have found it much better to deal with. The documentation is far more complete than any open system I have ever ran into with much better examples. I would never use it for general purpose programming but for engineering work it sure is hard to beat. So many things are built in that are nasty to try to implement in anything else. Things like the global optimization toolbox or the parallel computing toolbox make many things that are hard in other languages much easier to deal with.
MATLAB also takes backwards compatibility very seriously. If something is deprecated it warns and also gives an upgrade path and tells you what you need to change. That is the one thing that has seriously pissed me off about the free languages is backwards compatibility is just tossed out at a whim and you are left with a fairly nasty upgrade to deal with. Even now the vast majority of projects are still running Python 2 compared to Python 3. 10 years from now that will probably still be true.
In the end I care more about just getting work done now, not about any free vs proprietary arguments. I don't care if a language is open or not so long as it is very documented and runs on all the platforms I need it with a history of being well maintained. Modern development tools overall suck. We have javascript libraries that love to break compatibility every few months and people are constantly hoping from one new thing to another without getting any of them to the point where they truly work. We have languages deciding to just drop backwards compatibility. We have other languages that are just really buggy where software written with them tends to crash a lot. Software development needs to become more like engineering and that includes making the tools work better, sure they would not be developed as quickly but you would still get work done faster since the tools would actually work every time all the time.
Computer modeling for biotech drug manufacturing is HARD!
Let's look at the major programming environments of today:
1. Web
2a. Native Apps (machine languages (C/C++ etc))
2b. Native Apps (interpreted/JIT languages (intermediary byte code))
3, Mobile Apps
1. is made by 5 main technologies: XML, JavaScript, MIME, HTTP, CSS. To make it do anything you need another component, of no standard choice:your language of the server (PHP, Rails, .Net, Java, etc) .Net.
2. Was POSIX or Win32, then we got Java and
3. Is Java or Objective C.
We don't do things smart. There is no reason why web development needs to be 5 technologies all thrown together. We could reduce it all to Javascipt: JSON documents instead of XML/HTML, JSON instead of MIME, NodeJS servers, and even encode the transport in JSON as well.
Then look at native development. Java and .Net basically do the same thing. Which do what POSIX whas heading towards. Java was invented so Sun could keep selling SPARC chips, .Net came about because MS tried to extend Java and lost.
Then, we have the worst offenders. Mobile development. Not only did Apple impose a Objective-C requirement, but the frameworks aren't public. Android, the worst offender is a platform that can't even be used to develop native apps. At least Objective-C can. Why did Android go with Java if it's not portable? Because of some good requirement that they don't want to support a specific CPU, but then they go and break it so that you have to run Linux, but your GUI has to be Android's graphical stack. Not to mention that Android's constructs - Activities, Intents, etc are all Android specific. They don't solve new problems, they solve problems that Android made for themselves. We've had full-screen applications for years the same goes for theading, services, IO, etc.
I'm tired of reinventing the wheel. I've been programming professionally for 13 years now and Java was neat, .Net was the logical conclusion of it. I was hoping .Net would be the final implementation so that we could harness the collective programming power into one environment of best practices... a decade later we were still re-inventing the the wheel.
The answer I see Coming up is LLVM for languages. And Qt, a C++ toolkit. Qt runs everywhere worth running, and its one code base. Sure, I wish there was a java or .net implementation. But I'll deal with unmanaged memory if I can run one code base everywhere. That's all I want. Why does putting a text field on a screen via a web form have to be so different from putting a text box on the screen from a native app? It's the same text box!
Witty, a C++ webtoolkit (webtoolkit.eu) is mirrored after Qt and is for the web. You don't write HTML or JS, you write C++. Clearly the C++ toolkits are onto something. If they were to merge and have a common API (they practically do now) in an environment with modern conveniences (lambas (yes, C++11) managed memory) we'd have one killer kit. Based on 30 year old technology. And it would be a step in the right direction.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Never trust a programmer who doesn't like programming (or calls it "anagonistic" and "masochistic").
Perhaps you didn't understand the answer. It's pretty much 100% from both.
Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
"What would it be like if the only prerequisite for getting a computer to do stuff was figuring out a rough solution to your problem?"
Um... my experience programming has been that this is exactly what programming is all about. Getting someone's rough idea of a solution to the problem (if that much) and making something that will address it -- clients and users don't really know exactly what they want or exactly how to solve the problem. Nor should they. ...totally a sales pitch. Here's how I can magically eliminate the hard work part of the problem
Also, Republicans raped my wife and killed my child (or was it raped my child and killed my wife?) They busted down my door without a warrant(!!), chewing on the flaming remnants of the US Constitution. Then one of them told me to stop having gay sex with my live-in lover. Fucking fascists.
His name's Stroustrup. Bjarne Stroustrup.
Seriously, stop whining about OMG PROGRAMMING ARCHAIC.
So is eating and language in general, but you still do it the same way humans have been doing it for 150k years.
The problem is you, not programming.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
This guy seems to want an objects actions to be more apparent just from looking at the object, but he chose two rather bad examples. His math formula is as likely to look like gobbledygook to a non-math person as the program is. And the playing card has a fundamental set of rules associated with it that you still have to learn. You look at an ace of spades and you know that's an ace of spades, you know how it ranks in a poker hand, that it can normally be high or low (11 or 1) in blackjack or in a poker hand. But none of these things are obvious by looking at the card. If a person who'd never played cards before looked at it, he wouldn't know anything about it, either.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Damn Kids. It's Reagan's Fault!
Massachusetts liberals are not Liberals/Democrats, and for some reason they continue to vote for Democrats. They are Liberal Republicans to be simple!
*Woooosh!*
Stop underestimating people. Just because they don't think like you, doesn't mean they're stupid. Often, they can have a point that you just missed by thinking "problematically".
How much should you listen and speak to people?
I watched his Aurora demo, and much like the "Wolfram Language" that was brought up the other day, it didn't seem to be working at the same level as I do.
In the Aurora demo he made a To-Do list with his fake little HTML transform. That was fine, his list worked. But he didn't show changing the what the check-mark looked like. He didn't show us out to make it green. He didn't show us how to make the page behind it a different color, or the font-size marginally larger.
Sure, the concept of a To-Do list can be done in a few words of a high-level language...but that a program does not make. There is an infinitesimal number of other decisions/other command that must be defined and described. In the end, his cute little program would have to be just as long and complex as any JS or PHP script that did the same thing.
Perhaps he's just selling the 'Live Data' or the point-and-click editor, but as a programmer, (and him being a programmer) I find it disingenuous for him to present that as a replacement for the kind of detail and control that's necessary to actually accomplish the requirements of a customer.
--Welcome to the Realm of the Hawke--
I think there are other inputs as well, so "both" don't add up to 100%.
--Welcome to the Realm of the Hawke--
One old-school technique that has inappropriately fallen out of favor is the "comreg" (communication region). In modern terms: take all the parameters that all the layers need (which are mostly redundant), and toss them together in a struct and pass the struct "from hand to hand", fixing a the right bit in each layer.
I believe that's called the "command" design pattern, which encapsulates a request as an object.
I assume the OP must be thinking of DevOps as "just programming"?
If you select a programming language in which to program, then you run into all of the problems in the article.
If you choose a programming language in which to program, based on the needs of your scenario, then you run into very few of the problems discussed in the article.
If you create a programming language through which to solve the needs of your scenario, then the article simply makes no sense at all any more.
The article goes into multiple iterations of "in the real world, we describe like ; so why do we do it differently in programming?". The most memorable to me is when the author compares a picture of a playing card, the ace of spades, and compares it to "cards[0][12]", asking: "why can't we use the picture in programming?"
But that's just retarded. First off, we don't use the picture of the ace of spades when we speak. We use the words "ace of spades". And since that's incredibly ambiguous outside of a card game, we actually use "the card: the ace of spades", which is absolutely no different from cards[spades][ace], and we often enumerate cards in tutorials for bridge and for blackjack, so cards[spades][12] would be common. And in bridge, the suits have a sequence too, so cards[3][12] would be fine in context.
I think people forget that text came last -- after objects, after pictures, after speech, and way after gestures. Text is better. It's faster to transfer, faster to communicate, faster to scan, seek, read, and understand. It's more specific too.
But in everything in the real world, we manufacture a language specific to the task at hand. The word "grade" is an excellent example. In construction, geography, education, and manufacturing, the same word, with the same meaning, has entirely different semantics, usage, and even syntax. Welcome to jargon -- context/community/application-specific language.
What this article describes is the all-too-common practice is the programming industry of using construction tools (hammers, screwdrivers, nails, i-beams) as tools to teach children how to paint. Sure you can do it. And sure you can complain about how crummy a jack-hammer is at painting a canvas, but that's not the hammer's fault, nor is it the canvas's fault. It's your fault.
Read fail.
Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
Zealots of object oriented programming throw a fit, when they realize that no matter how much you force a metaphor, the computer doesn't give a shit. Translating any complex set of tasks into rudimentary instructions is inherently difficult. No magic language feature will change that fact.
NodeJS servers
Let me know when Node.js runs on anything smaller than a VPS. It appears a lot of people can't afford anything more expensive than shared hosting.
Android, the worst offender is a platform that can't even be used to develop native apps.
You can with the NDK. Or does some obscure carrier restrict use of the NDK in apps that run on Android devices on its network?
Not to mention that Android's constructs - Activities, Intents, etc are all Android specific.
And a lot of Windows constructs are Windows-specific, and if not that, Windows/VMS-specific. (Windows NT is a ground-up rewrite of VMS.)
They don't solve new problems
An "Activity" is just an open window, and an "Intent" is a mechanism allowing applications to register handlers for things other than file opening and URL opening. The way some of them were implemented is intended to allow the system to run for longer periods on a smaller battery.
For those who believe there is a silver bullet in programming for I have a bridge to sell.
Source code version control is critical. How else could you work on three separate bugs and two features without a way to keep it all straight?
THe blogger is just wrong There's a reason programming is the way it is, that is exists at the low level of abstraction that it does. Every 54 years (or perhaps every day) someone wishes out loud that programming was closer to natural language and common sense. This is a disguised (slightly) form of whats kown as the "frame" problem in AI. Basically,, everyday languageis (and concepts for that matter) extremely ambiguous but this factis disguised from us because we , as humans, have the proper frame" to ut speech act's meanings into, andtherefore render them relatively unambiguous(but look at howlaws are written to seeit already breaking down under the stress of having to increase precision) .
Yeah it would be greqat if we didn['t have to spell out absolutely everything tothe computer. But we do. Manuy people findprogramming less exactingthanmathematics (technically, it's not) and for this they should be thankful. Also, we are not codingin assembly (most ofus) and there's another reason to give thanks. The next logical leapto naturallaguage isnot aleap, its a chasm. Oh, and if we ever do cross that chasm,we won't be rogramminganyways, our computers, which willnow understand us, will also be doing the programmingfor us; by definition.
The original author is looking at the part of the problem that gets the most attention, but not at the part that causes the most problems. He's looking at programming languages and their expressive problems. Those are real, but they're not why large programs break. Large programs usually break for non-local reasons. Typically, Part A was connected to Part B in some way such that an assumption made by part B was not satisfied by part A.
C is particularly bad in this regard. C programs revolve round three issues: "how big is it", "who owns it", and "who locks it". The language helps with none of these issues, which is why we've been having buffer overflows and low-level security holes for three decades now. Most newer languages (not including C++) address the first two, although few address the third well.
There have been attempts to get hold of this problem formally. "Design by contract" tries to do this. This allows talking about things like "Before calling F, you must call G to do setup.", or "parameter A must be greater than parameter B". Design by contract is a good idea but weighed down by so much formalism that few programmers use it. It's about blame - if a library you call fails, but the caller satisfied the contract in the call, it's the library's fault. Vendors hate that being made so explicit.
it's a concept from aerospace - if A won't connect properly to B, the one which doesn't match the spec is wrong. If you can't decide who's wrong, the spec is wrong. This is why you can take a Pratt and Whitney engine off an airliner, put a Rolls Royce engine on, and have it work. Many aircraft components are interchangeable like that. It takes a lot of paperwork, inspections, and design reviews to make that work.
The price we pay for not having this is a ritual-taboo approach to libraries. We have examples now, not reference manuals. If you do something that isn't in an example, and it doesn't work, it's your fault. This is the cause of much trouble with programming in the large.
Database implementers get this, but almost nobody else in commercial programming does. (Not even the OS people, which is annoying.)
Chris claims that programming can be simplified so that the masses can program. Well he'd like to claim that, but at the moment he is only imagining. Let's cite some examples of things everyone will not be able to do with his new tool. Everyone will not be able to program a search engine such as Google's. Everyone will not be able to design a supervised learning task to find the needle in a haystack of data. Everyone will not be able to express the logic of their ideas, because they are simply ineffable to themselves
Even when you are adept in some field, when you hear of what the experts are doing in another field that you know little to nothing of, it seems like magic. Those who can write search engines, create statistical experiments and express the logic of their ideas will always be seen as magicians to non-experts. It doesn't mean that the tools they use are broken, though they might be, it means that there exists variation and degrees of expertise. Better tools is not going to change that, just shift the "problem" around.
No, they were quite clear that it wasn't 50% from one, and 50% from the other, or any other combination that would add up to 100% - the answer was "100% from both", as in "100% from nurture, *and* 100% from nature".
Their meta-claim was that you're not allowed to ask the question "what percent from this, and what percent from that", even though their general underlying assumption was that gender differences were primarily socially driven, rather than biologically driven. The could discern between the two sources, and even demand that the consideration of biological brain differences between genders was off-limits, but could not perform the simple task of adding parts to make a whole.
Put someone into programming when they refuse to acknowledge mathematical axioms because of their ideology, and they'll fail every time.
If they can't think "50+50=100", but rather, are so clever as to fool themselves into thinking "100+100=100", fine, they're not stupid, they're simply wrong and unable to program properly.
As mentioned, cognitive dissonance is fine in the human brain, but it's not conducive to problem solving in the real world.
Once they have demonstrated the basic skill of:
10 Print "Hello"
20 GOTO 10
They are considered part of the "community" - programmers. They aren't. As an example, take all the interest in the Raspberry Pi. An SBC intended to "teach kids how to program". In reality, most "kids" manage to get an LED to flash. According to the agenda, they are now programmers - the same same sorts of people who can write encryption algorithms, update software on Mars rovers and implement share-trading systems. It's like saying that if you can nail two pieces of wood together, you're a carpenter: here's your table saw (mind your fingers!) now go and build me a house.
The Linux community is little or no help either. With it's inaccurate and lazy view "with open source anyone can change it". What rubbish - nearly as stupid as "anyone can become president". It completely misses the point that 99% of the population wouldn't know where to start and most programmers are at the nailing 2 pieces of wood stage - despite their job titles and salaries and have neither the level of technical skill or experience, nor the correct, professional, approach to the subject.
Until we realise that the hard part of the job is design and the coding is the implementation, we'll continue to get new applications of the form:
Your application has just deleted all your data OK?
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
I started when productivity was measured in CLOCs, before C++ went ANSI. Today vs. then is so night and day, I wonder if the OP has any real sense of the big picture.
- Writing a line of code is done as a last resort when all attempts to avoid it have failed. (This comes from starting as a business, not software, consultant).
- Legacy code that has been debugged is almost always better than throwing out all of that QA. Wrap it and refactor it only as a response to bug report / enhancement + TDD.
- TDD, and the act of making software testable is far more valuable than the tests themselves. In my experience, regressions are few in maintainable testable code because it's maintainable and testable, not because of the tests themselves.
- Declarative almost always is better than imperative. See point #1.
Or do you think an inventor or composer has someone to hold xir hand while xe works on something new and awesome?
>My experience is that programmers are over 90+% *libertarian*.
Only the young or dumb ones. The smarter ones realize that not everyone is like us, we're all in this together, and western civilization has a lot of value.
90% ? ... A bold man he who pulls such a huge figure out of his ass
Also could you define libertarian ? no ? k thx bye.
Programming is hard because computers are dumb.
They have no common sense, but they are our only means to solve our most complex problems.
Our brains can only handle a limited number of details at once, so we use abstraction and assume the details we aren't thinking about will work out.
A symphony conductor does the same, but the players are smart enough to make it so.
Not so with the tool sets we know how to build today.
Can I glean anything from his writing?
Let me try the observability/Excell thing.
A programmer should be able to see what the program is supposed to be doing from the clear model in his head.
(Given that the model is never perfect because of the complexity/abstraction thing above.)
A warped way to describe debugging it to look at what is observable and try to figure out how the model could do that.
(If you can't figure it out, spot check with the debugger and add debugging code to the thing you are working on to test theories or get more observability.)
This is not a great situation and maybe Excell can teach us something to help this.
Excell is both fully visual and data driven.
Perhaps a tool set with data driven objects where the state of each object is visual.
Sadly, one would still have to learn to recognize the object state from it's visual signature.
(Just like having to lean what the visual cue for the Ace of Spades means.)
Well that didn't work. Perhaps someone smarter can glean something new here?
Programmer efficient increase when they can reuse some code from other programs to their new program but unfortunately sometimes they also copy and paste bad code from one program to another.
Out of my mind. Back in 5 mins.
Programming over the past decade has become a tar pit of corporate-sponsored development silos (Apple, MS, etc) usurping industry standards. Used to be, you learned C and C++, maybe Perl or Python, and SQL. Now all the different vendors use their own frameworks. Languages have exploded. Everything is the same, but different. This extreme fragmentation is one reason you have a "shortage" of people, as long as employers want people with experience in exact, vendor-specific technologies. I've used DB2, Oracle, MySQL, Postgres, etc but couldn't get a job using MS SQL Server. No matter what you learn, there's always some new framework. Struts? No, Spring MVC. No, ASP.NET MVC. No, whatever the flavor of the week is. Hibernate? No, Core Data, JPA, EF, whatever. The amount of churn means I can't keep up with learning whatever the flavor of the week is in APIs and frameworks. Too much churn and fragmentation! We need to get back to a small subset of industry standards.
I think the overall complexity level of tools is getting to the point of utter, total absurdity. Look at the J2EE toolset. You have JSP, JSTL, EL, and HTML, CSS, JavaScript, and jQuery on the front end. Spring MVC, Struts, or something in the middle. Hibernate, JPA, or something connecting to a database. Each new version of this stuff seems to break what used to work. Even tutorial books are almost instantly out of date this stuff breaks so fast. Then you have a constant churn of build and test tools. Ant works great, but people are switching to Maven for reasons I can't understand. JUnit, Jenkins, etc. No one can keep up with all this. Used to be possible to learn Make and a few other tools, and create a build process for almost any project.
Until the fragmentation and churn slows down, the computer industry is going to be mired in stagnation like it is at the present. We've had a wasted decade of almost no new innovations.
Again, you seem to fail to understand the answer. Here's a hint, math isn't reality.
Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
Instead of hinting, why don't you tell us what "100% from both" actually means? You've said twice that it's a perfectly fine thing to say but you haven't attempted to explain or define it.
Also, here's a hint, when you say 100%, it's math. (explanation: Say something like 'completely' or some other 'non-math' term if you wish to express something that can't be expressed by math.)
--Welcome to the Realm of the Hawke--
Since when did liberals do anything else except tear down Western Civilization?
One of the main reasons why programming is hard, is because computers are slow. This may sound very counter intuitive, but the fact that computers look like they are fast because they make use of many smart tricks, most of which we are no longer aware off. It is important to realize that computers all rely on the memory piramid, where in the top of the memory there is a little very fast memory and at the bottom there is a vast amouth of slow memory (often distributed in a system called The Internet). The range in speed and size is more than 9 powers of 10. A lot of effort is spend in copy data between the kinds of memory inside this memory piramid. And to be able to implement systems that appear fast, we have to deal with all the small tricks that are used in the system to make it look fast. Knuth has said that very often premature optimization is the root of all problems. The real fact is that almost every act of programming (in an imperative language) is an act of optimization, namely finding an implementation of a function with given constraints. Take for example the simple fact that whenever we deal with an integer in a program, it is an integer within a limited range. But an integer could be arbitrary large. So as soon as you declare an integer in your program, you are performing an act of optimization, because you decide that in your case the range of values within your function are limited to a certain power of 2. (Except if your language has an implementation for BigInt, but even these always have a limit.)
I notice that concerns tend to overlap in practice, especially in domain-centric programming (as opposed to base IT tools). The real world doesn't separate itself nicely into distinct chunks, at least not in a predictable way. Instead, concerns interweave in intricate ways.
We are stuck with 1D code (linear text) in a multi-D world (multi-factors), and any separation is merely a guess about future patterns, which often turn out to be flat wrong.
Table-ized A.I.
Congrats, someone else discovered 4th generation languages and the benefits they bring. Just wait another few weeks until discovering they're not universally applicable to problems. It's a real let down.
It's called software engineering. Most software is hacked, code-and-fix, cobbled together, unmaintainable dreck. Why? Because managers, clients, and customers blanch when presented with honest, realistic estimates based on metrics. So they'll often search out low-cost developers, eager (perhaps desperate) for work and who will agree to anything. They're probably minimally trained so they're not going to apply good practices (step-wise refinement, descriptive variable naming, OOA/D or SA/SD). They'll furiously churn out spaghetti-and-sausage-ware (not as tasty) that will miss the deadline anyway, barely work, but it'll be something. They invariably burn out and end up leaving and the next developer unlucky enough to be tasked with maintaining and extending the code will be blamed for taking too long for making changes because he or she will have to read, deconstruct, reverse engineer, and comprehend 100% more of the code than they would have had to otherwise.
As Fred Brooks said, there's no silver bullet. But all is not lost. Static analysis tools, code complexity tools can sometimes--I repeat sometimes--help target the 20% of the code that actually needs 80% of the maintenance effort. However, mention McCabe to most programmers and you'll most likely get a blank stare back.
While Chris aims to collapse time and technology layers to make an immediate, reactive environment, another way forward, or perhaps a way of leveraging it, is to make the environment more intelligent.
Much programming involves implementation of commonly understood patterns and thus can be automated, if the space is well understood.
I think a community project toward building an engine (call it an AI agent if you wish) that conceptually understands programming and can actually do it would be a good thing (... except because, SkyNet).
Such a system could have a unified understanding of a large project which would improve the deliverability of systems like obamacare or applications based on an open source stack, while empowering common users by leveraging the power of their own computers to help them solve problems and build their own tools, for example through chatting or drawing figures.
In the past I've imagined this as a way of utilizing more of the power of the desktop computer, to actually solve the user's problems and do common tasks that can be easily explained. A hot key that pops up a small window to chat with a bot would be more useful than Apple's Automator. As I have recently been spelunking in a system I have been asked to localize for an Asian language / net environment (based on drupal so tons of modules and deep undocumented complexity) I can appreciate anybody who would like to simplify herculean tasks.
It might be able to make sense of something as broad and chaotic as the obamacare system or the open source stack. I imagine it would be something a bit more intelligent than Frotz and could even help a child direct his own inquiry into the world around him or her. Computers have a lot of power and the next stage probably is finding out how to unlock their power without requiring years of study and hair-pulling. At least I would like to see systems gain introspection and share standard definitions of objects and functionality to reduce the replication of effort that is probably 90% of what developers do today.
Unfortunately, most people prefer to whine and complain that you didn't spoon feed them thoughts.
Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
...they'll either burn out, or even worse get promoted and you'll have to report to them. Yikes!
Since about 1783 til about 1968.
And you, jmc23, should never be a programmer if you believe math isn't reality :)
You are welcome to your own reality within the confines of your head, but when you code x=100, and y=100, I promise you that x+y==100 will register as false :)
Ah, the petty intellectual elitism that believes that ambiguity is wisdom :)
You're not spoon feeding thoughts, dear boy, you're blowing irrational smoke and pretending it's insightful :)
YOU should never be a programmer if you can't understand having multiple views on a single dataset.
Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
Please talk to your mirror elsewhere.
Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
Just trying to cultivate a habit of thinking in you :)
So, are you really going to defend the statement that gender differences are 100% from nurture, *and* 100% from nature"? Obviously you misunderstood the initial sentence, and found some semantic ambiguity there, but is this clarification clearer for you?
Or is the clarification and ambiguity both 100%? :)
My point exactly. Math is the reality of programming, period, full stop. Alternate, cognitively dissonant "realities" of liberal arts majors who can't grok fractions don't count there.
You shouldn't be a programmer if you don't understand that the reality of programming is math, even as you say "programming is based on math" :)
Keep digging all you like, this just gets more amusing as you go on :)
At least your inability to comprehend things, and then marvel at your 'genius' for pointing out how dumb others are because of your misinterpretations, amuses you.
Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
Sufficiently advanced programming is indistinguishable from the application.
I give you as example, the most successful class of object oriented programming languages: spreadsheets.
Star Trek transporters are just 3d printers.
Software engineering is indeed like mechanical engineering if you simply stop doing "fashionable" things and only do things which you can 100% understand and envision in your grey matter.
Stop pursuing the latest fad, don't do things you have no clue about, don't let yourself be pressured by Social Engineers, reject impossible objectives, piss of muppet managers.
THEN YOU CAN DO SOFTWARE ENGINEERING WORK.
With sufficient time and money you can then build things which will be more reliable than ANY mechanical, analog-electrical or hydraulic system that has ever been built. Computers have extremely low failure rates if properly done. They are almost perfect. Ask the A320 flight control software which has not killed you for more details.
Proper software engineering can be done in FORTRAN using notepad++. Plus Word or LaTeX to properly capture requirements, nail down design decisions, document semantics of data structures/files and so on.
We don't need more Rapid Shite Generators. We need proper time, proper money, proper education and LESS AMATEURS in the data processing business.
Apparently too many people are in a precarious situation, so they perceive data processing/computer science as some kind of holy grail. Can't they stick with their Social Worker thing ???
German software engineer with a CS degree
A bit of projection there, don't you think? :)
You were unable to comprehend that the statement "100% from both" was literally meant "100% from A *and* 100% from B", even after it was clarified to you. When pointed out, you dodged and marveled at your 'genius' by claiming that your real goal was to "cultivate the habit of thinking in others".
And now, when it's all laid out in the light of day, just how wrong your initial assumptions were, and how silly your follow up defenses were, you dodge again! :)
Brilliant!
You were touching a "pornografic" subject. Like asking "how many muslims can a european.style society possibly absorb". The answer clearly is "not that much", as Islam is clearly a tyrant's ideology which preaches that women are second-class persons. It is jealous like a rabid dog. Read their little book of hate and it becomes clear.
The lefties don't want any answers to this kind of questions, so they bullshit you.
You really need to become much, much more cynical to live in this world.
My stuff is fast from day one because I know what I do. I have an education, I read relevant stuff, I am not an amateur. I don't know your problems.
The answer is 100% from both, literally. YOU fail to understand the answer.
Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
Of course it's 100% from each.
Here: 5 times 7 equals 35. How would you portion out responsibility for the 35? 7/12 and 5/12? Seems wrong. 7/35 and 5/35? Aside from being a tautology, doesn't total 100%. I'd say in this case 100% each is the best answer for most purposes.
Back to gender differences: if you raise two kids of different gender absolutely identically, the difference would be 100% nature. If you take two kids of the same sex and raise one as a boy and one as a girl, the differences will be 100% nurture. For anything in between, the differences will be not only anywhere between 0:100 and 100:0, but there will be an interaction which is not necessarily additive, or multiplicative, or well behaved in any way. Could well appear as a lot of random unconnected dotsv all over n- space. (Given that gender difference is not a unidimensional parameter)
We've made a huge amount of progress thanks to Cartesian reductionism. That doesn't mean that everything succumbs to it; things are nonlinear, nonmonotonic, full of singular points, and/or just plain holistic.
Ask your mother to partition her love for you by % into pride, familiarity, possessiveness, hormonal response, concern, altruism, loyalty, public pressure, whatever else comes to mind.
And that's one trouble with programming; applying analytical principles to problems where they don't fit.
Star Trek transporters are just 3d printers.
Also, here's a hint, when you say 100%, it's math. (explanation: Say something like 'completely' or some other 'non-math' term if you wish to express something that can't be expressed by math.)
Good advice, actually.
Star Trek transporters are just 3d printers.
Are you again avoiding the clarification? When asked, they replied that when they said "100% from both" they meant 100% nurture *and* 100% nature.
Are you trying to defend that 100%+100% = 100%?
Really?
Wait, so you're saying that 10 nurture times 10 nature = 100 total, and therefore the result is 100% nurture *and* 100% nature? That somehow nurture and nature must be multiplied together before coming to a whole? :)
Really? :)
Look, you can make the argument that some specific gender differences are more driven by nature, and less driven by nature, and you even argue that they can vary over time, but you cannot assert that gender differences are 100% driven by nurture *and* 100% driven by nature. That's simply unicorn rainbow thinking.
And that's the trouble with believing that anyone can program - not everyone can apply analytical principles to problems.
Nuff said
for the article, but the basic premise is correct; major steps remain to make programming better, improvements that cannot simply be dismissed as adding training wheels for the unskilled.
For example - code may remain text-based, but it desperately needs to be decoupled from the file system.
The reason this happened is the Internet.
Web sites are, more often than not, built in assembly line fashion, where a slicer/front end guy turns layered graphics files (Photoshop, InDesign, Illustrator) into HTML/CSS/JS/JQ, then a different guy marries this to a framework (Yii, Zend, Code Igniter, PHP Storm, Word Press, Ruby, whatever), and then yet another guy runs Q/A. Most of this stuff gets written in horribly ancient non strongly typed threaded interpreters, essentially MS-DOS Basic made to look like C. In other words, the perfect environment to code in without any architectural/design skills at all.
It's a very efficient way of building "consumable software" - software with a three to twelve month life cycle, and it's perfect for cheap offshore labor. Get the creative done in South America, the slicing done in Romania, the coding done somewhere else...
So now management believes that large, complex systems can be built using this model, as they can't tell the difference between a facebook user generated content submission sweepstakes and a business intelligence analysis application.
Spend a few years in Digital Interactive, which is where most of the world's programmers live now a days, and you'll realize that the Internet is what has set programming back a decade, because it's all about QUANTITY not QUALITY. Something that's only going to live a year only has to be good enough to work and not one fraction better.
Murphy was an optimist
The trouble is that the people who recruit programmers have no way of distinguishing a genius from a fake.
When I started 44+ years ago, the hard part of programming was getting programs to fit the memory size and processor speed of the computers of that day. We often wrote in assembly language, because it was often the only reasonable choice. Scientific code was written in FORTRAN, business code in COBOL (or maybe RPG). A little later C came along and became a viable alternative to assembly language for many things. There was much experimentation with languages in those days, so there were a lot of other languages around, but FORTRAN, COBOL, and C/assembly were the major ones in use.
One thing we did have in those days, which I recall with great fondness, were manuals. There were manuals for users of computer systems, and manuals for programmers, describing the operating system and library interfaces. There were people who specialized in writing such manuals, and some of these people were quite good at it. But at some point manual writing became a lost art, and the industry is poorer for it.
Over time, the machines reached a level of capability that exceeded the requirements for the kind of programs we were writing. It was rare to find a program (code, not data) that wouldn't fit in memory, and compiler technology had advanced to the point that we didn't need to obsess about the speed of code sequences in assembly language. So we started writing larger and more complex programs, and the main difficulty of programming was managing and testing the code. Source code control systems were developed, and eventually continuous build systems, but testing remains an important concern to this day.
As computer networking evolved, the problems of managing concurrency and asynchronicity became more severe. Many approaches have been developed to deal with these problems, such as threads and monitors, but this remains an area of difficulty, and is more important than ever with the advent of multicore processors.
By the mid-90's, we'd learned about all we could from the structured programming craze, and were well into the thrall of object-oriented programming, with many of us programming in C++. Large teams of programmers became common, and for them, source code control and continuous build systems were essential. Then the web finally arrived on the scene, and a great war between corporations for control of the web platform began.
How did that war end? Well, everyone lost. We got HTML, CSS, and JavaScript. Some people call that a platform. I call it an abomination. But the alternative would have been to have no standard at all, which I'm sure would have pleased some of the combatant corporations, but was never really a viable option.
Now we are in the age of frameworks. Everybody and his dog has a framework, and most of them are very poorly documented. I believe that it is only by virtue of forums like stackoverflow that some of them are usable at all. But many of them are aimed squarely at dealing with the problematic "web platform", and for that we should all be grateful. However, we really need to get some smart people together and design a new web platform, including a reasonable migration path from the current mess. The problem is, as we approach the 20-year anniversary of the web debacle, there is an entire generation of programmers who have never known anything else.
The nature of programming will continue to evolve, but evolution is not a particularly efficient process. If we are indeed intelligent, we should be capable of intelligent design.
The area this guy would like to focus on is called "essential complexity", or the part of the problem that can't be avoided. This is in opposition to the artificial complexity, or the stuff we add in, which is only there because of how we chose to solve the problem this time. This is established and understood already (at least by those of us who have been around for a while). He didn't have to rediscover these concepts from scratch via interviews.
Which brings me to the real problem with programming: NIH (not invented here). Using any sort of established approach would suck the fun right out of programming for the newer developers. So each generation (about 10 years in programmer time) re-invents everything: languages, coding styles, idioms and conventions, data interchange formats, management styles, estimation fads, "best practices", inter-process communication mechanisms.
Those of us who have been around over 20 years can clearly see that we're just running in circles now. Genuine advances that actually stick are few and far between. The real reason here is the turnover: with few sticking around more than 15 years in the business, there is no ability for the average practitioner to develop expertise beyond a certain level of sophistication. Those who do stick it out are stuck with practices that never mature. (And no, the younger set does not listen to our advice or try our ideas to see if they might be better. That wouldn't be "fun".) (And, yes, we do try new things all the time. That's why we see so many things for the second or third time, and recognize them so quickly.)
C++ even works on Windows Phone.
True of Windows Phone 8, not of Windows Phone 7.
You can't really ban a language that compiles to CPU opcodes.
The device's manufacturer can if it designs the device's operating system to refuse to execute any CPU opcodes that aren't digitally signed by the manufacturer. For example, the manufacturer could configure the device such that trying to P/Invoke from a downloaded application raises a security exception. The only native code on a Windows Phone 7 device is that which comes bundled with the phone. Third-party applications under Windows Phone 7 are effectively C#-only. (Technically, third-party applications can use any language that compiles to verifiably type-safe CIL that uses the .NET Compact Framework, but in practice that means C#.) The only way to run CPU opcodes in a third-party application on Windows Phone 7 is to include an interpretive emulator of said CPU written in C#, which is such an inefficient abstraction inversion that I didn't mention it at first. This changed in Windows Phone 8, but devices that shipped with Windows Phone 7 cannot be upgraded to Windows Phone 8.
a sufficiently large company.
Not on Xbox 360 unless you're a sufficiently large company. Xbox Live Indie Games is C#-only
do you think that every title that is released on PS4 and 360 is completely re-coded into .Net for the 360?
No, because games developed and published by "a sufficiently large company" aren't sold through Xbox Live Indie Games. Games sold on disc or through Xbox Live Arcade are allowed to be in C++, but this option is available only to "a sufficiently large company." Games sold through Xbox Live Indie Games are C#-only.
Then it's a context object such as the "drawing contexts" from several graphics APIs, right?
But this just reinforces me point. We are choosing fragmentation
No, the majority of the market is choosing devices that enforce fragmentation. We are outliers compared to the majority.
You can sign any binary, executable or DLL
That doesn't mean the device will accept your signature. There are four trust levels in Authenticode: none, code signed by a publisher with a certificate signed by a trusted CA, "Microsoft" (code signed by Microsoft), and "Windows" (code signed by Microsoft that forms part of the operating system). In WP7 and XBLIG, only "Windows" can run native code, and only "Microsoft" can run at all without a valid subscription to whatever Microsoft is calling "Creators Club" this year.
C++/CLI or C#.
Standard C++ compiled in C++/CLI is not verifiably type-safe. The vast majority of the subset of C++/CLI that is verifiably type-safe is a syntax error in standard C++. And the common subset of verifiably type-safe C++/CLI and standard C++ appears to be a toy language that lacks any pointers or references at all.
I was always a pretty competent coder, but I hardly ever code these days. I'm perfectly happy thinking in logical terms -- my problem is keeping the logic in my head while I spend several days coding around the logic. When I'm fighting with syntax, eccentricities in library execution etc, I have to not only think about the problem logic, but also the language logic, the library logic, etc etc etc. This is what Grainger calls "incidental complexity" -- everything other than the problem at hand. It distracts from solving the actual problem, and it places a massive unnecessary cognitive load on the coder. It becomes frustrating and limiting, and you sometimes find at the end of the day that you haven't coded exactly what you intended to, because you were so distracted. But all that incidental complexity means that it's very difficult to unpick your code and rewrite it to what you wanted. Incidental complexity is very bad both for the experienced and inexperienced coder.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Liberal Republicans are no longer welcome.
HTML5 has all sorts of client side processing and XML is sent back and forth between servers and clients in a blizzard of unnecessary tags.
If REST is so fucking obvious why were so many web apps written that weren't RESTful?