|
This might come as a surprise to readers not into computer programming, but professional and hobbyist programmers alike all use the same tools as we did 60 years ago — one-dimensional, sequential plain text. It’s like writing a single document in Word without using any formatting, with the goal of instructing a large symphony orchestra to perform a complex musical piece. That app you’re using could as well have been built in the 1950s, had we the same powerful hardware back then. We are thoughtlessly using Grandpa’s old toolbox to build a spaceship. Your favourite fancy-pants modern programming language is from the 1950s.
|
|
|
|
|
What an idiot. "Writing code" just works. Nothing better has come along because there (probably) is nothing better.
Would you want to try dragging and dropping images? It's very limited in what it can do. Currently I'm writing a lot of SSIS packages -- and it just sucks! It's horrible to work with and in a many many cases I'm left writing code anyway.
How would you discuss problems and solutions with colleagues if you can't use words to do it.
I'm just glad I never used punch cards or switches.
|
|
|
|
|
We're also using glass in our windows, which is essentially the same technology that the ancient Egyptians were using in 2000 BC.
We're also using clay bricks to make houses, which is essentially the same technology that the ancient Mesopotamians were using in 3000 BC.
We're also using water to bathe ourselves, which is essentially the same technology that has been used since before the last ice age.
Invent something better if you don't like it.
|
|
|
|
|
Rasmus Andersson-
I'm amazed that the majority of people commenting on your article have a 'what we have is as good as it can get ' mentality. I think from the first line of your article I had a bit of an epiphany--not one that I can fully explain yet and not one that I would dare describe to a seemingly short-sighted group of peers.
Several contributors point out that processors execute operations in a sequential manner, and that it 'all comes down to 1s and 0s in the end' or something like that. Well guess what guys, assembly language takes a certain variant of programming discipline to do well. And even at that level, while you are telling the processor to load data and executable code with values in registers from specific memory segments, even assembler is an abstraction. Assembly code is compiled down to the actual bit values that a processor can understand.
My point here is that as programming has evolved; we've seen the introduction of object-oriented languages. Yes, of course it still all comes down to bit vales for the processor at run-time, but OO design helps us as HUMANS to take abstract needs and use the concept of classifications (more often than not called classes) to allow ourselves to create solutions for complex real-world business requirements using a much higher level of abstraction.
Even modern OSs and run-time platforms help us to abstract with high-level languages because we don't have to worry about handling the threads notifying our applications of events triggered by the user, e.g. button clicks, scroll bar movements, etc. We are to a certain extent freed from a lot of the mundane, thanks to the OS, the compiler and in many cases the run-time support. And let’s not forget the extensive pre-built libraries we have at our disposal.
Yes, we have all of the above, better ways to organize software using classes, conceptual tiers for separation of concerns, software designs lending themselves to extensibility and reuse. But as Rasmus points out, we still sit at a console typing text to ‘classify’ much of these pieces of code, and defining how they will interact once they become objects during program execution
Text is linear, even when defining classes that may interact in a multidimensional manner when used in an application.
We use linear text to describe how multiple threads should run simultaneously. That is certainly an example of using a one-dimensional language to describe a multi-dimensional process.
Rasmus Andersson is perhaps a bit too forward-looking for the audience here (no put-down intended). I happen to think he is quite correct in challenging future creators of development tools and environments to take us to the next level, where we can concentrate more on the problem, in an abstract way, much more in the way the user would describe it, and be able to translate the solution in a manner that is more efficient than writing text for the most part (although I will always believe in the ability to get to the lowest-level instruction layer when needed).
In any case, whether you happen to agree with Rasmus or not, we may want to prepare psychologically for a future in software design and development in which being adept at writing code textually in a classic IDE is of diminishing value, and the ability to embrace radically different tools that increase productivity immensely are going to be what keeps us as good developers in business.
|
|
|
|
|
Well, there is Alice, which I used in college years ago to create games in a graphical environment.
And then there are the multitudinous designers available (e.g., Entity Designer, Windows Forms Designer, WPF Design Surface, SharePoint Workflow Designer, markup designers, and so on).
And there are IDE's like Code Bubbles that are textual, but add lots of graphical niceties.
|
|
|
|