Finally learning C++!

[Symbology]

All the semicolon is, is a terminator character to tell the compiler or runtime machine that it has reached the end of a string of commands. You can make languages that have no apparent terminator character, but I quite like the capability to decided, visually, when to end my code rather than have it implicit as in the case of termination by the return character. There are occasions when it helps to be able drop down a line and continue one command.

I heartily agree. You should have the choice. Just not the requirement.

 

if I were to type:

if (this_condition == true)
      abstract.object.search.then.get.something()
      = abstract.object.construct.and_then.do.something()

in an implicit language it wouldn't work because the (literally) stupid compiler would read it as ending the command with each line. Where as in an explicit termination language you have the ability to choose when to finish a command; thus, one is able to write multi-line segments of code and terminate at leisure.

I agree. I further think that the compiler should be able to recognize when you are through and where the next statement begins regardless of any terminators.

 

In my observation, if your going to go on a rant regarding the totalitarian nature of coding languages, you might consider some of the more obvious "features" such as:

{}, These do the same thing in JAVA and C that the ; does; they just terminate the method or class instead of the individual commands.

() these are used to enclose parameters in Java and C; why use them when you could just use return characters instead? Can you imagine it?

do.something
parameter_one, parameter_two

Amen brother. Or how about LISP and its use of () :)

 

Lets take it up a notch why not throw out the totalitarian nature of standardized language all together I dont like punctuation anyway it just gets in the way of my communicating exactly what I mean I mean I can just use letters in strings any way to represent what I mean right I think this makes my point rather well actually ;)

Very much so. If I pay a little attention I can make out where you were ending one thought and beginning another. Though it sometimes requires a second or third pass to be sure. But these days computers are not short on processing speed for such things.

 

The thing is, semi-colons do for C and C++ the same thing that commas, and semi-colons do for the English language. You might as well complain about the "period Nazis."

I was actually thinking about that very point as I was writing my previous post. Glad you pointed that out. I agree, but I'll have to start that over in the linguistics thread :shrug:

 

 

Aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it deosn't mttaer in

waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the

frist and lsat ltteer be at the rghit pclae. The rset can be a total mses and

you can sitll raed it wouthit a porbelm. Tihs is bcuseae the huamn mnid

deos not raed ervey lteter by istlef, but the wrod as a wlohe.

 

Amzanig huh?

[alexander]

Don't know what you guys are talking about... i dont have any problems with semicolons or commas or brackets... consider the following code to get the joke:

ORG $DAC0
ENT $DAC0
MVI A,$54
CALL $4B44 ;print T on screen
MVI A,$49 
CALL $4B44 ;print I
MVI A,$4D  
CALL $4B44 ;print M
MVI A,$45 
CALL $4B44 ;print E
MVI A,$20  
CALL $4B44 ;print space
MVI A,$3D 
CALL $4B44 ;print =
MVI A,$20 
CALL $4B44 ;print space
LXI HL,$F934 ;load address of tens of seconds
MOV A,M  
CALL $4B44   ;print seconds
LXI HL,$F933 ;load address of unit seconds
MOV A,M  
CALL $4B44   ;print
CALL $12CB ;wait for keypress
JMP $5797 ;jump to menu
END

[IDMclean]

Aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it deosn't mttaer in

waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the

frist and lsat ltteer be at the rghit pclae. The rset can be a total mses and

you can sitll raed it wouthit a porbelm. Tihs is bcuseae the huamn mnid

deos not raed ervey lteter by istlef, but the wrod as a wlohe.

 

Amzanig huh?

 

I want a programming language which can handle that.

[Buffy]

I want a programming language which can handle that.

Actually, it's a simple lexer problem! You could do it with just about any programming language!

 

The only thing is that you'd need to add a simple restriction on identifier names, like say, prepending all of them with an underscore, and then you could loosen the lexer so that it recognized all keywords by guessing off the first character and word length and doing the same with the identifiers....

 

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning, :phones:

Buffy

[Symbology]

A quote from an excellent book I am reading right now:

You should figure out programs as you're writing them, just as writers and painters and architects do.

 

Realizing this has real implications for software design. It means that a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you've already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that's not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.

- Paul Graham

Hackers and Painters p22

[Buffy]

Yah, it also brings to mind something I like to call "four-valued logic": true, false, "don't know" (null), and "whatever"....

 

Age is mind over matter. If you don't mind, it doesn't matter, :)

Buffy

[alexander]

i have a problem with that quote.... i can definitely relate to part of that, the problem is that without static grounds, you can not create good code. The concept he is describing has started taking shape in a form of visual programming, the problem is, like anything it generates dirty code. Its like creating web pages in Dreamweaver, while a designer might do it to speed up the creative process, a seasoned coder will tear the code into pieces and create a much more stable, much more robust piece of code. The platforms you describe have started taking shape in forms of RoR and CakePHP, for web development, and .net platform, and such, for regular applications. for now, all are fairly inefficient, however all allow the dev to quickly piece a piece of working code together, without having to reinvent wheels, and then spend the free time, hopefully making those wheels into tweels and moon rovers, for others to use to make other things :eek:

 

hope you dont get confused....

[sanctus]

KickAssClown, in fortran you have something similar to that: if at the start you do not write

implicit none 

everything starting with a-h and o-z is by default a real number and everything starting with i-n is an integer...

[Symbology]

i have a problem with that quote.... i can definitely relate to part of that, the problem is that without static grounds, you can not create good code. The concept he is describing has started taking shape in a form of visual programming, the problem is, like anything it generates dirty code. Its like creating web pages in Dreamweaver, while a designer might do it to speed up the creative process, a seasoned coder will tear the code into pieces and create a much more stable, much more robust piece of code. The platforms you describe have started taking shape in forms of RoR and CakePHP, for web development, and .net platform, and such, for regular applications. for now, all are fairly inefficient, however all allow the dev to quickly piece a piece of working code together, without having to reinvent wheels, and then spend the free time, hopefully making those wheels into tweels and moon rovers, for others to use to make other things :)

 

hope you dont get confused....

 

Clearly bad code can be written in any language. And certainly sloppy code can be written in a language that has non-strict typing. The difference is the sloppy code will run (ok at least limp) in the flexible language, while the strict type language sits and eyes them suspiciously - remaining a prohibitive barrier to new programmers getting into the field.

 

I know there are those that feel this is a good thing. But personally I think there is a wealth of creativity out there held by domain experts who are not programmers and the entire gray scale of programmers in between. And they all deserve forgiving tools like Excel that will let them be as creative and sloppy as they would like. If correct answers matter, they will spend sufficient time to get it right to the level that they need.

 

It's fine that there are still powerful languages like C and Assembly that allow the hard core programmers to work their performance mojo, but for the other 98% there are pedaflops of computing power to make up for their lack of 6+ years of formal training in CS.

 

A further personal opinion - that seems to be shared by others like Paul Graham is that many of us that are formally trained and capable of writing thousands of lines of strictly typed syntax , precisely matched brackets, and meticulously terminated semicolons would actually rather spend our time adding content instead of syntax - and let the computer figure out the picky details that it needs to line everything up - in much the same way as we currently use a calculator instead of doing the math by hand, or using a word processor with a back space key instead of having meticulous typing skills on an old Selectric, or worse a Quill and Ink. If it is repetitive and rigorous let the computer do it.

 

I think if C were an art form - Pointalism would be its closest metaphor. At a distance it works, but if you look close at all it ceases being intelligible to any but those trained in the form.

 

http://upload.wikimedia.org/wikipedia/commons/thumb/5/5d/Seurat-La_Parade_detail.jpg/200px-Seurat-La_Parade_detail.jpg[/img]

[Buffy]

Clearly bad code can be written in any language. And certainly sloppy code can be written in a language that has non-strict typing...

 

But personally I think there is a wealth of creativity out there held by domain experts who are not programmers and the entire gray scale of programmers in between. And they all deserve forgiving tools like Excel that will let them be as creative and sloppy as they would like. If correct answers matter, they will spend sufficient time to get it right to the level that they need.

Oh but they won't ever be "Software Engineers!"

 

Seriously though, there's sooooo much more to this than strong typing:

....many of us that are formally trained and capable of writing thousands of lines of strictly typed syntax , precisely matched brackets, and meticulously terminated semicolons would actually rather spend our time adding content instead of syntax - and let the computer figure out the picky details that it needs to line everything up - in much the same way as we currently use a calculator instead of doing the math by hand, or using a word processor with a back space key instead of having meticulous typing skills on an old Selectric, or worse a Quill and Ink. If it is repetitive and rigorous let the computer do it.

Sure, but that's what syntax-directed editors do for you. No one should really even be expected to do this.

 

What really makes for "Software Engineering" is--as Edsgar sez--proving that it will work in all cases. Hey, let the editor tell you the syntax is wrong or the argument types don't match. Where you *really* get bugs is being sloppy about boundary value problems, incomplete logic and unhandled exceptions: are you *sure* you're handling all possible inputs? Buffer overruns? Shared memory semaphore management? Multi-statement transactions? Deadlock detection? Etc? Etc? Etc?

 

That's the stuff that takes brains, but that even "super-coders" quite often have never been trained to do.

 

And that's why there are so many gol'darned bugs!

 

If all else fails, immortality can always be assured by spectacular error, :hyper:

Buffy

[Symbology]

Oh but they won't ever be "Software Engineers!"

 

Seriously though, there's sooooo much more to this than strong typing:

 

Sure, but that's what syntax-directed editors do for you. No one should really even be expected to do this.

 

What really makes for "Software Engineering" is--as Edsgar sez--proving that it will work in all cases. Hey, let the editor tell you the syntax is wrong or the argument types don't match. Where you *really* get bugs is being sloppy about boundary value problems, incomplete logic and unhandled exceptions: are you *sure* you're handling all possible inputs? Buffer overruns? Shared memory semaphore management? Multi-statement transactions? Deadlock detection? Etc? Etc? Etc?

 

That's the stuff that takes brains, but that even "super-coders" quite often have never been trained to do.

 

And that's why there are so many gol'darned bugs!

 

If all else fails, immortality can always be assured by spectacular error, :phones:

Buffy

 

All excellent points. Then I was thinking about it for a minute... Hey wait... why should a driver have to care about drive belt tension, vacuum leaks, or oxygen mixtures? For that matter, in the future, hopefully no one would have to concern themselves with tire pressure or even fuel levels. Who really cares if it is a fusion reactor or 10 million exothermic bacteria under the hood as long as it gets you down the road at the speed you want to go, at an affordable price?

 

Race car drivers and car aficionados certainly do. When you care about the difference between 140 vs. 210 mph or 27 vs. 45 mpg then such things make a difference. For that matter there are entire web sites on how to perfectly drive a Pryus to maximize fuel efficiency. But for those people it's all about driving, and very little about where they are going or what road side attractions they just coasted past.

 

I would say my car is much like what I would like to have in a computer language. It has a neural network watching my shifting habits when I have the transmission in manual mode, and can mimic them perfectly when I decide to shift back up to Automatic in heavy traffic. I set my thermostat at the temperature I want, and the car's computer decides whether I need heat or air conditioning based on outside vs inside temperatures - and it can compensate if I have the sun roof open. It doesn't give me a big pop-up on the windshield telling me that I have a heat threshold violation [simultaneously turn the key, press the gas, and lock the doors to reboot now]. Traction control sensors can realize that I am being a bit too overzealous and govern the torque being delivered from any of the wheels. It knows what I wanted to do, and it can provide the fudge factor to make up for the deficits in my driving skills.

 

Even though I personally can only get up to about 10mph on my own, with a simple mash of the pedal I can break 100 with that nice pinned to the seat g-force when I want to. I can pop the trunk, put the back seats down and haul some decent sized cargo when I need to as well. It may not have an 18 wheelers cargo room, or the g-forces of an Indy car. But it doesn't have 23 gears to shift through or require a team of 8 just to fuel up either.

 

I will admit that having built in hash tables is a fun feature to play with, and that multi-threading is the way to go when designing an MMORPG client. But nothing like that is required to run complex stock financial analysis, Fourier Transforms, Mathcad optimization, or any other real world use for a computer.

 

Car mechanics have had diagnostic computers for a decade or two now. I heard them complain mightily to begin with, and gripe about the large expense, and draconian requirement for their use by the car manufacturers. But I have noticed a shift in the last 5 years of so. Nowadays all the mechanics just consider it a normal part of their tool set, just like a car lift, and a tire balancing computer. And these days they sing its praises because they can hook it up to the car and in a matter of seconds have an instant read out of what's wrong, and what the computer has been doing to adjust for current mechanical and/or driver issues.

 

Over that time frame the machines have come down in price, gone up in reliability, and industry standards have been established - just the normal process of getting the kinks worked out of a new system. But I hope at some point that we can have digital assistants as well that can provide automated metrics and adjustment on our software.

[Buffy]

All excellent points. Then I was thinking about it for a minute... Hey wait... why should a driver have to care about drive belt tension, vacuum leaks, or oxygen mixtures? For that matter, in the future, hopefully no one would have to concern themselves with tire pressure or even fuel levels. Who really cares if it is a fusion reactor or 10 million exothermic bacteria under the hood as long as it gets you down the road at the speed you want to go, at an affordable price?

 

Race car drivers and car aficionados certainly do. When you care about the difference between 140 vs. 210 mph or 27 vs. 45 mpg then such things make a difference.

Absolutely, but remember, you're *designing* the car, not just *driving* it!

 

I know a thing about this analogy: I love to drive cars, but I have no idea what makes them tick (although I do know what makes certain ones tick better than others!). :cheer:

 

But I'm still a *long* way from designing a car or quite frankly even fixing it or diagnosing it's problems when it breaks. I can say it's "loose" or "tight" in the corners, but I really know nothing about how many spacers to put in the springs or how to adjust the camber on the suspension to fix it.

 

This analogy may get across the difference between when you use a spreadsheet or Dreamweaver versus having to actually use a tool to actually build a *program*, but the issue that's much more difficult is what should programming tools actually *do*.

It may not have an 18 wheelers cargo room, or the g-forces of an Indy car. But it doesn't have 23 gears to shift through or require a team of 8 just to fuel up either.

 

I will admit that having built in hash tables is a fun feature to play with, and that multi-threading is the way to go when designing an MMORPG client. But nothing like that is required to run complex stock financial analysis, Fourier Transforms, Mathcad optimization, or any other real world use for a computer.

Actually, I think its pretty easy to argue that very few programmers these days have the luxury of not having to think about either multi-user or multi-processing applications!

 

Now I'll be the very first to say we need better tools. In fact I've spent a good portion of my career actually on the bleeding edge of building such tools.

 

But they're *hard* to build.

 

Solving some of the problems I mentioned in my previous post really are problematic, not only in the number of possibilities you need to cover, but the complex interactions that start popping up even when you're doing something as simple as a popup with a progress bar or catching an Ajax server message in a browser.

 

Now Edsgar was right about dissing the kinds of "Visual Programming" tools we had 20 years ago (if you haven't, go back and click the link in my earlier post and read the whole lecture!), but that's not to say that a visual approach is the wrong one: just that they have to be designed with the realization that they have to actually *add* to the productivity of the developer.

 

Car mechanics have had diagnostic computers for a decade or two now. I heard them complain mightily to begin with, and gripe about the large expense, and draconian requirement for their use by the car manufacturers. But I have noticed a shift in the last 5 years of so. Nowadays all the mechanics just consider it a normal part of their tool set, just like a car lift, and a tire balancing computer. And these days they sing its praises because they can hook it up to the car and in a matter of seconds have an instant read out of what's wrong, and what the computer has been doing to adjust for current mechanical and/or driver issues.

That is if they're useful! The first versions of those gizmos were useless from what I heard, and since they went from pure *monitoring* of the existing mechanical systems to actually being the interface for *digitally driven* systems, they're actually good for something!

 

But really this is about the tools that actually *automate* the process, so:

... I hope at some point that we can have digital assistants as well that can provide automated metrics and adjustment on our software.

...just scratches the surface. In fact we've already got these with the testing tools that are out there. And while there are tools that do more formal design (e.g. Rational and other neo-CASE tools), they're too painful and limited to use for mainstream programming.

 

What a lot of it comes down to is that as developers, we want to automate the process, but we want complete control at the same time. You need to be able to work on many levels at once, dropping down in detail where you want to, and that dramatically increases the complexity of what the tools have to do.

 

So really, you're on the right track, but beware of oversimplifying the problem. We've got a long way to go....

 

Automatic simply means that you can't repair it yourself, :phones:

Buffy

[alexander]

Clearly bad code can be written in any language. And certainly sloppy code can be written in a language that has non-strict typing.

Its not even the sloppyness of the code, its the fact that the code is not written by the programmer, it is the code that is generated by the system, and programmers that had to make the code much more generalized for it to have more then a specific application.

The difference is the sloppy code will run (ok at least limp) in the flexible language, while the strict type language sits and eyes them suspiciously - remaining a prohibitive barrier to new programmers getting into the field.

Debugging your own code is how you learn the language syntax and complex logic. i dont see a program not running because of a syntactical mistake a bad thing, and i almost always use a text editor with syntax highlighting which greatly aids in this stage.

I know there are those that feel this is a good thing. But personally I think there is a wealth of creativity out there held by domain experts who are not programmers and the entire gray scale of programmers in between. And they all deserve forgiving tools like Excel that will let them be as creative and sloppy as they would like. If correct answers matter, they will spend sufficient time to get it right to the level that they need.

So use excel, and dont claim to be a programmer. If you are an artist, you learn to use a coloring instrument to express your art. If you are a musician, you learn your instrument, and how music works to express your view point. If you are a writer, you learn the deep workings of the language to better express your feelings. It is only fair to learn simple rules to be able to express yourself through code...

 

It's fine that there are still powerful languages like C and Assembly that allow the hard core programmers to work their performance mojo, but for the other 98% there are pedaflops of computing power to make up for their lack of 6+ years of formal training in CS.

I can teach you how to code in 3 months, and you will not know a syntax of any particular language... coding and is not about language syntax, it is not about the language power (which is a topic on its own, every language is powerful, you need to know how to use the apparent advantages and disadvantages to use the power, and that comes with knowing coding logic) You dont need 6+ years of education, most good, and most of the best coders never finished college, and their MBAs now were gotten after they started writing their brilliant code!

 

A further personal opinion - that seems to be shared by others like Paul Graham is that many of us that are formally trained and capable of writing thousands of lines of strictly typed syntax , precisely matched brackets, and meticulously terminated semicolons would actually rather spend our time adding content instead of syntax - and let the computer figure out the picky details that it needs to line everything up - in much the same way as we currently use a calculator instead of doing the math by hand, or using a word processor with a back space key instead of having meticulous typing skills on an old Selectric, or worse a Quill and Ink. If it is repetitive and rigorous let the computer do it.

 

Then use Python... semicolons are a way to make a language white space insensitive, so if you dont like them, then use a language that is white space sensitive.... it'll teach you to properly format your code, too...

 

Where you *really* get bugs is being sloppy about boundary value problems, incomplete logic and unhandled exceptions: are you *sure* you're handling all possible inputs? Buffer overruns? Shared memory semaphore management? Multi-statement transactions? Deadlock detection? Etc? Etc? Etc?

Yes, those are the problems that take a lot more time to figure out then the 5-6 semicolons you may have missed, it is incomplete logic, or improperly expressed logic that makes you spend most of the time debugging. Rarely does anyone write a piece of code that does all the proper checking and has flawless logic, especially if its a complex app, with complex algorithms. It is not a problem of any language, it is a problem of the very expression of your ideas, Symbology, and no matter the syntax, you will still be faced with more time spent debugging then coding, no matter how smart of a system you have, it will not complete the logic that you, as a creative "program creator", have missed!

 

why should a driver have to care about drive belt tension, vacuum leaks, or oxygen mixtures?

similarly why should a user worry about memory leaks and security issues that the program creator did not care enough to look at, because they didnt care for sloppy, generated code?

 

as a programmer you are the architect, the mechanic, the designer, the engineer that designs the car, and you better know exactly the tension of the belt, vacuum leaks and the oxygen mixture, infact you set all of those things, and you monitor all of those things, you make the car work. If you want to design a new reactor, you dont throw some fuel into some propelling mechanizm, add some cooling and call it fusion drive.... because without knowing what the fuel is, and what it produces, you dont know what propelling system you can effectively use, and how much and what kind of cooling you will need to keep the reactor from breaking (reactor here meaning any kind of a reaction-based mechanizm anything from a water spinning a wheel to a nuclear fusion...)

[alexander]

on to finish my thought, though my arm is aching from typing (gah, broken bones != fun)

 

Programming is not about the language or the syntax, i find that anyone who knows how to "program", not just throw syntactically correct lines together to solve simplistic problems, does not care what language to develop in. If you asked them to write code in Zygwygafirmian, a programming language i just made up to illustrate this point, knowing the logic, they can, within a week write mostly any code, within a month be completely profficient with the language, within 3 months know enough to write a book on the language, syntax is something you reference back to the reference manual to, logic is what programming truly is, logic, care for data, and efficiency are the factors that drive the best coding practices... IMHO

[Symbology]

Absolutely, but remember, you're *designing* the car, not just *driving* it!

 

I know a thing about this analogy: I love to drive cars, but I have no idea what makes them tick (although I do know what makes certain ones tick better than others!). :evil:

 

But I'm still a *long* way from designing a car or quite frankly even fixing it or diagnosing it's problems when it breaks. I can say it's "loose" or "tight" in the corners, but I really know nothing about how many spacers to put in the springs or how to adjust the camber on the suspension to fix it.

 

Actually I had intended that the vehicle would represent the language/compiler/IDE. That is something that I have a personal interest in designing, but I don't expect the rest of the drivers/programmers out there to have to worry about it.

 

It is the vehicle that lets me deliver my product - whatever that is. It runs on universal highways such as ODBC, XML, the Net, and Transaction Processors. And it can be replaced [black box] in the future and I could still deliver my product with the latest and greatest hovercraft model. Of course if I have alot of crap in my vehicle then I may have to contract some local movers to help me port my program/business practices into the next model.

 

It might look like a program right now. But really all I have defined is an information flow and process. If it ports to something in the future that is no longer a program, that is fine by me. For example Genetic Programming might replace our legacy software in the future and implement it in wet ware.

 

 

What a lot of it comes down to is that as developers, we want to automate the process, but we want complete control at the same time. You need to be able to work on many levels at once, dropping down in detail where you want to, and that dramatically increases the complexity of what the tools have to do.

I completely agree. I have always been in awe of SAS and how it allowed a rookie programmer to deliver an impressive graph and set of tables across massive amounts of data with 4 lines of code (that had no loops in it!) But it also allowed me to create very detailed and complex data scrubbing algorithms when needed.

 

I have always tried to deliver UI's that had guidance for the rookie users, but also got out of the way of the veteran users to let them be productive. I think all systems should have that range of flexibility, but I rarely find it anywhere. To my observation it really requires talent to design two systems that are interwoven and built to scale.

 

Automatic simply means that you can't repair it yourself, :evil:

Buffy

Thanks for the great quote!

[alexander]

Actually I had intended that the vehicle would represent the language/compiler/IDE

 

but the car does not produce anything, therefore the analogy perception is faulted.

 

lets break down programming terms for a car:

 

raw materials - assembly code, lowest level of language, something that defines objects that linkers use to link the code

 

nuts and bolts - linking objects, raw materials put together in their small sequences to make small objects that are common in all code

 

parts - for our intents and purposes these are groups of nuts and bolts put together to form more vague objects that we as programmers put together to make the car

 

the car - the end user product, its the ultimate top in the chain, you do not use multiple cars to make something else, thus the car represents and end-all product

[Symbology]

Debugging your own code is how you learn the language syntax and complex logic. i dont see a program not running because of a syntactical mistake a bad thing, and i almost always use a text editor with syntax highlighting which greatly aids in this stage.

Do you think it would be a good thing for your car to crash if you didn't execute a curve precisely? Or do you think that having a well designed machine that has built in forgiveness and flexibility to handle and recover from error might be a better alternative?

 

 

similarly why should a user worry about memory leaks and security issues that the program creator did not care enough to look at, because they didnt care for sloppy, generated code?

 

as a programmer you are the architect, the mechanic, the designer, the engineer that designs the car, and you better know exactly the tension of the belt, vacuum leaks and the oxygen mixture, infact you set all of those things, and you monitor all of those things, you make the car work. If you want to design a new reactor, you dont throw some fuel into some propelling mechanizm, add some cooling and call it fusion drive.... because without knowing what the fuel is, and what it produces, you dont know what propelling system you can effectively use, and how much and what kind of cooling you will need to keep the reactor from breaking (reactor here meaning any kind of a reaction-based mechanizm anything from a water spinning a wheel to a nuclear fusion...)

 

Metaphorically speaking, I'm not talking about designing a car. Instead I want to be able to deliver a process and a business that is compelling for my customer. I don't care if I am controlling a single vehicle or an entire fleet from the comfort of my design chair. In fact I would prefer that I could outline the process once and then hit the execute button and watch the fleet of vehicles self generate as needed based on the work load. In fact the vehicles could be invisible for all I care, as long as the data/product flowed reliably.

 

That's the nice thing about the Internet. I have no idea what hardware/software got the bits from me to you and back again. But I do care how it looks once it gets there. And just like Hypography that gets a face lift every few months, but still delivers the legacy conversations when requested - having a language that ports easily from version to version is going to become an increasingly important feature. For example Amazon and Yahoo have massive code bases that will need to be ported in the future. It is really the processes that were the intention of the original programmers, not some particular implementation.

 

A language that can recognize the atomic units of the precious cargo it holds, and can be able to translate from one grammar to the next will, I think, become a very valuable feature to any IT shop in the future. Such a system would then be able to be both white space and punctuation tolerant.