Menu
News
All News
Dungeons & Dragons
Level Up: Advanced 5th Edition
Pathfinder
Starfinder
Warhammer
2d20 System
Year Zero Engine
Industry News
Reviews
Dragon Reflections
White Dwarf Reflections
Columns
Weekly Digests
Weekly News Digest
Freebies, Sales & Bundles
RPG Print News
RPG Crowdfunding News
Game Content
ENterplanetary DimENsions
Mythological Figures
Opinion
Worlds of Design
Peregrine's Nest
RPG Evolution
Other Columns
From the Freelancing Frontline
Monster ENcyclopedia
WotC/TSR Alumni Look Back
4 Hours w/RSD (Ryan Dancey)
The Road to 3E (Jonathan Tweet)
Greenwood's Realms (Ed Greenwood)
Drawmij's TSR (Jim Ward)
Community
Forums & Topics
Forum List
Latest Posts
Forum list
*Dungeons & Dragons
Level Up: Advanced 5th Edition
D&D Older Editions, OSR, & D&D Variants
*TTRPGs General
*Pathfinder & Starfinder
EN Publishing
*Geek Talk & Media
Search forums
Chat/Discord
Resources
Wiki
Pages
Latest activity
Media
New media
New comments
Search media
Downloads
Latest reviews
Search resources
EN Publishing
Store
EN5ider
Adventures in ZEITGEIST
Awfully Cheerful Engine
What's OLD is NEW
Judge Dredd & The Worlds Of 2000AD
War of the Burning Sky
Level Up: Advanced 5E
Events & Releases
Upcoming Events
Private Events
Featured Events
Socials!
EN Publishing
Twitter
BlueSky
Facebook
Instagram
EN World
BlueSky
YouTube
Facebook
Twitter
Twitch
Podcast
Features
Top 5 RPGs Compiled Charts 2004-Present
Adventure Game Industry Market Research Summary (RPGs) V1.0
Ryan Dancey: Acquiring TSR
Q&A With Gary Gygax
D&D Rules FAQs
TSR, WotC, & Paizo: A Comparative History
D&D Pronunciation Guide
Million Dollar TTRPG Kickstarters
Tabletop RPG Podcast Hall of Fame
Eric Noah's Unofficial D&D 3rd Edition News
D&D in the Mainstream
D&D & RPG History
About Morrus
Log in
Register
What's new
Search
Search
Search titles only
By:
Forums & Topics
Forum List
Latest Posts
Forum list
*Dungeons & Dragons
Level Up: Advanced 5th Edition
D&D Older Editions, OSR, & D&D Variants
*TTRPGs General
*Pathfinder & Starfinder
EN Publishing
*Geek Talk & Media
Search forums
Chat/Discord
Menu
Log in
Register
Install the app
Install
Upgrade your account to a Community Supporter account and remove most of the site ads.
Enchanted Trinkets Complete--a hardcover book containing over 500 magic items for your D&D games!
Community
General Tabletop Discussion
*Geek Talk & Media
Describe me the computer programmer of the future
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="wocky" data-source="post: 2662344" data-attributes="member: 11408"><p>Programming software is always a deal between at least two (but often more) parts. You always have a programmer, and an expert in the subject the program will help with. Sometimes the programmer is the expert, but this is rare in bussiness environments. Between programmer and expert there might be an analyst, who interviews the expert and tries to grasp what might be called the "Bussiness logic", and all knowledge of the subject needed to make the program. An analyst then lays down this knowledge in a "model", that represents the problem in a "language" (diagrams, explanations, etc.) that might be understood either by a "software designer" or the programmer himself (if he's doing the designing). The analyst and designer might be the same person as well, though analysis and design are tasks to be done separately.</p><p></p><p>In what's called "Machine language programming", the programmer knows the in and outs of the specific computer hardware he's writing for, and gives more or less direct instructions to this hardware. At this level programming is hard, and requires thinking in terms of computer concepts, and not bussiness concepts. The programmer is king, because the analyst or client (and probably the designer as well) won't have a clue of what the program does or how. At this level, it's usual for other programmers to really have to strain to understand what the program does as well.</p><p></p><p>Then there's "Low level programming", which shields the programmer from the hardware, but still makes him program using pure programming concepts. Programs are more "readable", but beyond the grasp of an analyst (or designer, perhaps). It's easier to program at this level, so bigger and more complex programs are possible.</p><p></p><p>In a "High level programming language" the line between programmer and designer breaks, since programming is done in "High level concepts" (objects, bussiness rules, logical prepositions, etc.) High level programs should be more readable and very easy to understand by peers. Programming becomes very fast if the right language is chosen for the task (some high level languages are general, but some are very specific). These languages are more complex internally (since there's an intermediate level at which high level concepts are converted to machine instructions), and require extra computing power... so though they have existed for years, they weren't always used.</p><p></p><p>The future should see a trend to higher level languages at which a designer/programmer is no longer needed, and an analyst can work by himself. "Expressing the solution to a problem" should become a synonim with "Programming"; i.e. if you can precisely explain what you need, you can have it. These languages will rely on internal AI to make assumptions and choose solutions, and have huge libraries of small reusable programs (the LEGO block approach mentioned).</p></blockquote><p></p>
[QUOTE="wocky, post: 2662344, member: 11408"] Programming software is always a deal between at least two (but often more) parts. You always have a programmer, and an expert in the subject the program will help with. Sometimes the programmer is the expert, but this is rare in bussiness environments. Between programmer and expert there might be an analyst, who interviews the expert and tries to grasp what might be called the "Bussiness logic", and all knowledge of the subject needed to make the program. An analyst then lays down this knowledge in a "model", that represents the problem in a "language" (diagrams, explanations, etc.) that might be understood either by a "software designer" or the programmer himself (if he's doing the designing). The analyst and designer might be the same person as well, though analysis and design are tasks to be done separately. In what's called "Machine language programming", the programmer knows the in and outs of the specific computer hardware he's writing for, and gives more or less direct instructions to this hardware. At this level programming is hard, and requires thinking in terms of computer concepts, and not bussiness concepts. The programmer is king, because the analyst or client (and probably the designer as well) won't have a clue of what the program does or how. At this level, it's usual for other programmers to really have to strain to understand what the program does as well. Then there's "Low level programming", which shields the programmer from the hardware, but still makes him program using pure programming concepts. Programs are more "readable", but beyond the grasp of an analyst (or designer, perhaps). It's easier to program at this level, so bigger and more complex programs are possible. In a "High level programming language" the line between programmer and designer breaks, since programming is done in "High level concepts" (objects, bussiness rules, logical prepositions, etc.) High level programs should be more readable and very easy to understand by peers. Programming becomes very fast if the right language is chosen for the task (some high level languages are general, but some are very specific). These languages are more complex internally (since there's an intermediate level at which high level concepts are converted to machine instructions), and require extra computing power... so though they have existed for years, they weren't always used. The future should see a trend to higher level languages at which a designer/programmer is no longer needed, and an analyst can work by himself. "Expressing the solution to a problem" should become a synonim with "Programming"; i.e. if you can precisely explain what you need, you can have it. These languages will rely on internal AI to make assumptions and choose solutions, and have huge libraries of small reusable programs (the LEGO block approach mentioned). [/QUOTE]
Insert quotes…
Verification
Post reply
Community
General Tabletop Discussion
*Geek Talk & Media
Describe me the computer programmer of the future
Top