Is the art or programming going away?
KaosKidd
Posts: 296
Not too long ago, several very helpful and lengthy discussions of programming languages brought many pro's and con's to the surface, but not one really looked at what's happening today within those languages: Microsoft Lightswitch
Code Writers, HUMPH! While in the long run to do save time, and soft costs and maybe even some hard costs, but it's stuff like this that could lead people like me to feel obsolete in today's programming world. The software's awesome; it does deliver something of a standard that does work. Now, there's no accounting for programmer's flair and creativity; things that have been replaced during some software update years ago.
<sighs> Oh well, I know that most of the young programmers using this stuff couldn't do the code manually, and when there's an issue to be solved, it's either the old folk like me or the web for the answer. It's sad to note that us old programmers won't even fill in the gaps as programming consultants in this battle; the web is far much cheaper and faster. In short, this proves that in today's world, even a programmer must have other talents within the workplace if they are to survive.
KK
Code Writers, HUMPH! While in the long run to do save time, and soft costs and maybe even some hard costs, but it's stuff like this that could lead people like me to feel obsolete in today's programming world. The software's awesome; it does deliver something of a standard that does work. Now, there's no accounting for programmer's flair and creativity; things that have been replaced during some software update years ago.
<sighs> Oh well, I know that most of the young programmers using this stuff couldn't do the code manually, and when there's an issue to be solved, it's either the old folk like me or the web for the answer. It's sad to note that us old programmers won't even fill in the gaps as programming consultants in this battle; the web is far much cheaper and faster. In short, this proves that in today's world, even a programmer must have other talents within the workplace if they are to survive.
KK
Comments
I remember programming from the 80's because there were more brands of computers but unless you get involved with Linux, the average computer club near me only shows you how to operate the internet or how to configure Outlook Express.
The mentality out there is why sit and program when you can just buy it? My answer is there isn't a one size fits all and I would rather program in multi-color than vanilla.
You are basically competing with companies which have billions in research and make money from advertising.
Yah, I agree. My employer has stated to me my most valable asset to the company is that I'm not only a programmer (by trade) of many languages or platforms, but I'm a technician by hobby, network admin, analysis and enginer, and database manager, analysis and enginer (by training). Were we to hire anyone for the IT department, they would need some aspects of it all as well. We're not a programming shop, we're a payroll processing plant, with highly custimized options that require programming in many different forms; PS, WSCRIPT, CSCRIPT, DOT NET support for C# and BASIC, and macro languages for Excel, Outlook. It took me nearly forever to get my employer to let me deploy web services which lets me consolidate the various scripts and dependancies i've created over the years.
Recently, I build several T4 (Text Template Transformation Toolkit) scripts for my team. T4 is code generator that you’ll find in Ligthswitch and Entity framework. Anyway, XML is the input and a strongly typed object is the output. So, what used to take a bunch of tedious typing can be done is a few seconds.
Isn’t one of the main ideas behind OOP is to build reusable black boxes?
With all due respect to all the developers and REAL programmers out there, I honestly believe the definition of a computer programmer should be reserved for Assembly Language Developers only. The rest, myself included, of us are merely using the assembly code designed by the "old folks" to get our Higher level development to to work.
People always say that higher level languages are so easy to use without regard to assembly/machine code. If I had started my programming hobbies in assembly language to start with, I believe it would have been easy, but since I started with QB45 then on to VB and to C#, I think I spoiled the educational experience I could have had if I had started with assembly language in the first place.
I jump at the chance to purchase modern books written about assembly language in hopes that I can someday write pure assembly language software. Books like "Code: The Hidden Language of Computer Hardware and Software"
I rely on the "Old Folks", the assembly languages developers, to write books like this to continue learning. The problem is that there are not enough modern books on the subject.
I don't believe assembly language is all too difficult as long as there are proper reference materials that can be refered to by anyone willing to learn, I even pay for it if the price is reasonable for the page count and information. That's why I love using the propeller micro controller, Parallax has all reference material freely available for their products, while also having hard copies available for a reasonable price.
When I got the manuals on the Intel/AMD processors, also freely available, I had too much information and didn't know where to even begin, and there were too few examples and not enough books on machine code from those that know it well. Maybe they're too busy programming, or think that nobody will read or use their information.
After I purchased the book "Code" above, I didn't put the book down until I read it completely which took a whole day. Everything is basically in layman's terms and extremely easy to read and understand. I would do the same for any other modern or old books on assembly I find.
So please all you old school machine code gurus, please write more books, articles, essays, and examples so we can all see the light. AND put those resources in an easy to access place.
That being said, I also believe that you "Old Folks" and gurus are not appreciated enough for your time and effort. So with the utmost respect:
Thank You!
http://www.amazon.com/Introduction-Intel-Family-Microprocessors-Hands/dp/0138934398
As a retired programmer (29 years experience) I think you are way off base.
Without higher level languages, system development would be mired in the muck. Writing large scale database and financial applications in assembly would never fly.
Object oriented languages and specialized relational database tools (like MS SqlServer, IBM DB2, etc) would never have been practical with low level interfaces.
Assembly in the microcontroller environment is a totaly different animal...
This stuff is the reason that anything I code is targeted towards those that truely use computers (e.g. those that enjoy coding and understanding what is going on). I do not go for vinilla, it does not cut the mustard, EVER.
I have always had the philosophy that you learn a new CPU by doing some Machine Language programming for it, then you can use assembly. C, BASIC, Pascal, etc, should be reserved for code that others will have to be able to read. C++, C#, Oberon, Ada, Smaltalk, Delphi, OO Pascal, etc., should be reserved for End Users (not the domain of programmers). And if you can not code it your self DO NOT use some Rapid Application Development system, learn how to code it (regardless of the language that you use).
I can agree to the extent of ease of use, but if there were no higher level languages, we would all know assembly therefore making it easier to use, and we would still have all the nice GUI's we use today, but with all assembly code. Take GUI's like RadASM for example, they are making it easier to design interfaces with pure assembly. If you can use A GUI like VS, you can use RadASM with some ease. It's too bad that it is mainly designed for the Win32 environment, but still a good tool to easily make x86 assembly user interfaces using drag and drop.
I would agree that portability across different architectures would be a pain, but had the entire development community used pure asm code, tools would have been made long ago to cover that. The same with specialized database tools.
My comments are not to offend anyone, they are based on the what if's.
A real programmer works in assembler - I don't think so, if my creations (outside the Propeller world) were not usable across Intel, ARM, IBM Power and whatever other platforms I would be out on my ear. Some kind of portable high level language is essential.
A real programmer does not develop WEB apps - I don't think so, I have seen some very amazing things going on in that space. Even if I do think the whole world of HTML, PHP, Javascript etc is a total mess:)
A real programmer won't use VB, Java, C# etc. - I don't think so, ...
Think about this: There is a thing call the Discrete Fourier Transform, it's compute intensive, you can hand craft that algorithm in assembler until you are blue in the face. For any useful size of data it will always be too slow to be practical.
Then one day in the 1960s John Tukey dreamt up a way to speed this up greatly, the Fast Fourier Transform. The speed gains are dramatic, in the order of thousands and more as your data size grows bigger.
Turns out Tukey did not code that for the first time, that was done by J.W.Cooley. Turns out Tukey did not even like to go near a computer.
Looks to me like the best programmers, as in algorithm designers, don't program at all:)
I doubt seriously that we WOULD have GUI interfaces. Windows is millions of lines of code (mostly some variant of C). If it were written in assembly it would be billions of lines.
There is a lot more to developing systems than just writing code. Being able to easily maintain and make modifications to existing code is paramount. You need to be able to follow code written by someone else and modified by lots of other developers. Low level languages make this much more difficult and time-consuming. Stringent coding standards are needed to faciliate maintaining systems and development costs dictate that commercial systems use higher level languages.
COBOL and mainframes are still alive and well (see IBM) because PCs and servers still can't handle every computational need.
I wasn't offended. There are a lot of misperceptions about what "real" programmers are and what they do.
I used to have rookie programmers working for me who only wanted to write "new" programs.
Good luck with that! That is not a real world environment.
Users' wants and needs change frequently and unfortunately a lot of time must be spent in meetings, impact studies, etc before any code changes are made.
GEM (even the newer versions for 68k/coldfire) could be rewritten in ASM in about 100,000 lines of assembly fairly easilly.
Menuette OS is a small 100% assembly GUI based OS written by a single person. Yes it is short on features, that is just a resault of being a 1 man project.
There is no reason that modern GUIs have to be written in a HLL.
If the goal is communication, the most universal of programing languages are ideal. Convention is quite important.
If the goal is secrecy, a new and difficult language is forthcoming.
If the goal is speed, the lowest of levels and a heavy focus on purpose are deployed.
If the goal is cost, you can go just about anywhere at any given point in time.
For myself, it wasn't until I got involved with Linux and returned to the fundamentals of Unix and C programing that I began to feel I was learning in a useful fashion with engineering clarity. Proprietary OSes have a tendency to try to herd their users into dependence on their product and so lack the genius of generic engineering. A lot of hardware manufactures do the same with digitally controlled equipment.
I guess I should be asking, "What is the art of programing?" After all, the core problem is that it is different to different people
Assembly programming for large complex programs is very tedious and time consuming. Debugging them is even worse.
High level languages make programmers more productive and reduce the tedium and cost of writing software. It would be nice if there were fewer of them and they followed standards better so they could be used across multiple processors and operating systems.
That is not to say that assembler will ever go away. It will be needed for many reasons. I enjoy writing programs in both spin and PASM but even the largest of those programs are much smaller and simpler than most PC programs. Without high level languages we would not GUI based operating systems, the Internet, or the World Wide Web.
That being said, I do feel the "art" of programming seems to be getting lost in a maze of specialty languages. I work with programmers that may know how the code fits together to make something work, but it's a brute force mentality more often than not, and all the subtlety of the code, the "art", is lost in it. They don't have enough of a grounding in the basics of what code does at it's simplest form to make valued judgement calls on code modification. They tend to solve one problem by creating another. I use words like "compact", "efficient", and "contiguous" and they look at me like I have a third eye in the middle of my forehead. They respond with "memory is cheap and we can always upgrade". I still remember having 56K of memory to work within, and EVERYTHING had to fit in that space. My girlfriend is learning SQL right now in an attempt to get out of a job I'd hang myself if I was forced to do it, and her son wants to go into video game programming. She is learning to create tables and manipulate databases from a shell command line interface, but her son thinks learning to create a new background in a flash game somebody else wrote is "programming". At the end of the day, they will both know some "programming", but she will have a more thorough understanding of the hows and whys than her son will because she DID start off at a lower level interface than he did.
It's less about "How low are you working at" than it is "how low did you start to learn".
I have found that on most OSes on most CPUs that debugging large assembly programs is a lot easier than debuging large HLL programs. Now for smaller programs the tools for debuging HLLs do provide an advantage.
As to development time, I have found that Assembly is often faster, because you have to test every routine as you create it and thouroly document the interface or each and every routine, this eliminates much of the debug time that is seen with large HLL programms as the bugs that exist in the way routines interact tend not to creep up in assembly due to the needed level of documentation for each. this greatly reduces the development time for larger projets. Yes small projects are developed much faster in a HLL
I do not understand how spending less time to end up with better, less buggy, programms is considered less productive. This is the resault of developing in assembly, see the top half of this post.
It is said that in assembly you should have an average of two lines of comments to each line of code and in a high level lang you should have an average of 8 lines of coment to each line of code
Bearing in mind that most assemblers are specific to the chipset they are designed for, the point of HLL is to allow for more portability of code than is allowable with pure assembly language. If not, we'd have a re-write for every new processor that comes on the market. If that were reality, there would be no computer industry because it wouldn't be cost-effective, and we'd all be digging ditches or teaching math.
I do agree that the art of programming is not about what language you use though rather the well thought out algorithms. And it does not realy matter what language you choose to implement them in.
I only argue in favor of Assembly for large projects, where using assembly SPEEDS UP development. For smal projects (under about 80000 instructions compiled) HLLs have some huge advantages.
From your post I must note:
Developing in assembly is a lot easier and faster than developing in HEX Machine Language.
I deployed one leg of a Health Information Exchange application in our test environment at work. This is a large app with a lot of moving parts across multiple systems and platforms. I can not image how building this thing in assembly would have been faster than using high level languages.
Can you provide an real life example?
In the past people had written assembly language translators to go between various CPUs, this is not doen any more because the universities teach us not to use asm (whitch I dissagree with). So we have a way to go between CPUs for portability.
As far as going from one os to another:
You can write tool kits, and shared libs, for assembly language as easily as for a HLL. So we can have full portability in asm.
The only issue I see is failure to match the available tools to the task at hand.
On the other hand, I think that if you do not at least know how to program in Assembler, you don't know how to program. Programmers who have learned in Javascript and who don't really even know how the computer works are an ever more common problem; when the SQL server starts grinding or the browser freezes they have no basis to even figure out what might be happening and how they might ask the HLL to do it a different, more practical way.
And any HLL which does not bound check and automatically manage memory is the worst of both possible worlds, denying you both the performance and control of asm and the safety and convenience of sensible errors and easy debugging. Third letter of the alphabet, I'm lookin' at you...
I guess we will just have to agree to disagree. I have programmed in hex and assembler (8080, Z80, 6502, 6800, 6809), as well as HLL's (C, Basic, Fortran, Cobol, PL1, SQL, etc),. Mainly I think that disagreement is about the definition of an HLL. Once you have macros or subroutines written to perform operations how is using them any different than using the instructions of an HLL compiler? Both perform more complex operations that require multiple machine language instructions.
As for assembly language translators, true, they can give us some way for assembly language portability between CPU's, but differences between architectures may still require a single instruction for cpu A to be translated into multiple instructions for cpu B and vice-versa. Again, similar to an HLL compiler.
In any case, the argument for high level languages is more that of programmer productivity. A programmer can learn a small number of HLL's and be productive on a variety of cpu's rather than spend time learning the architectures, assembler quirks, and details of a large number of cpu's.
Heck, I know web developers that would have a hard time describing in any technical detail the difference between a GET and a POST but they can build a web site.
So many varied opinions, all of which have merit. For me, and my humble opion, the art of programming is as stated; not the languages you program in, but, more closely related to how you would go about solving a problem. While I am "studied" and fluent in several languages, most of today's programmers don't know that 50% of a programming challenge is not really the coding, it's more of the selection of what needs to be done where.
Quick example. I have several SQL stored procures that do what SQL does best; store and retrieve data. Attached to these stored procures, in methods that go well beyond what would be considered advanced, are actual DLL's (VB6 compiled code) that does what SQL can't do (nicely). The art of programming in this example was figuring out the best approach to the problem.
My professors of years ago taught us that programming in ML has it's time and place; such as VB (pick your flavor), C, C#, or any of the other complied HLL's. The art of programming as I see it is to produce clear, concise, functional, error free and error trapping code that preforms the tasks as needed using as few resources in the process.
During my tenure as a "floor programmer", a process I wrote was actually 7 separate executable applications that acted on a progressively filtered / processed data file. One was in ML, simply for it's speed and direct access; this was the toughest but smallest application. One was VB6 because of it's advanced manageable string handling, another was C# due to it's speed and memory management. A few MS DOS batch files simplified the feeding of file names into the C and VB applications, and a single VBScript that ran the whole process. This was written nearly 9 years ago, and recently was edited by me so it could access a larger memory model. I was humbled by the company owner when he told me that they tried several times to re-write the process, to make it faster, and failed.
So for me, the art of programming is not only being able to code in any of the flavorful programming languages, but to know the best features of each language and the targeted environment the application would run on, and then create an application that does what needs to be done. This returns me to my original statement; For a programmer to survive in today's world, they must have other talents to offer their employer.
KK
I would really like to hear you argue your case against some one like Linus Torvalds.
There is no way that Linux would have become what it is if it were written in x86 assembler. Even Linus said that his original creation would only ever be x86 only, just because that is the only machine he had access to at the time.
As a practical matter, you have said effectively that there is no problem to write cross-platform code in assembler because there are translators from one assembly language to another. Does it not make more sense to abstract all assembly languages into something a bit more understandable like C?
At worst if you have 10, say, architectures you need 10 different code generators. Rather than 9 translators from one unreadable assembly language to the others. Yes it might be 10% less efficient than hand crafted assembler, but then so would translating one assembler language to another.
As a case in point, years ago I ran all my companies 8085 assembler code through conv86, a program from Intel that translated 8 bit 8085 asm to 16 bit 8086 assembler. The resulting code ran at half the speed of the original, despite the processor being 16 bits and having twice the clock rate.
Had that code been writen in a high level language it would have done better.
So cross-platform capability is going to cost you in terms of both RAM and speed, depending on how broad a set of architectures you want to support and how well. The difference between a language like C, which manages to be a crappy HLL and a crappy assembler at the same time, and real HLL's and assemblers is one expression of this. If you try to do everything you end up doing nothing well. These languages succeed only because computers keep getting faster so that nobody really cares if things are done well.