The first thing I remember learning about programming was to number the lines by 10s for flexibility. What's a file?
Flow charts and number by 10
Did not vote cuz 'what the what?'
What's a file?
It's where you keep your paper documents. You know, like printouts of your programs.
That's a little tool I use to make things fit because I was sloppy at the milling machine. It also helps you get into things if you can't find the right screwdriver.
Who needs more than one line to do something interesting?
That reminds me of a friend of mine that showed me a one liner terminal program for the C64. Neat stuff.
UNIX? They're not even circumcised! Savages!
Why would it matter of Eunechs are circumcised?
Why would it matter of [sic] Eunechs [sic] are circumcised?
Circumcision is an indicator of whether someone (in this case, eunuchs) is a savage. This can be taken at face value, but it works even better as a way to draw attention to the premise. What is it that the speaker finds civilized about cutting the foreskin off infant penises? The apparent absurdity of the practice leads the reader to question the judgment of the speaker.
But wait! The author didn't actually use the spelling 'eunuch,' which was clearly intentional. Why would the author use the name of a well known computer operating system instead? Does the absurdity of circumcision somehow apply to Unix? Is there something 'savage' about it? Are readers being trolled into putting too much thought into a throwaway line that was merely intended to highlight the homophone?
We may never know the author's true intent, but the insight gained from analyzing it will stay with us for a long time.
Sign on Rabbi's shingle:
TODAY'S SPECIAL !!!Today Only -- CircumcisionsHalf Off !
that is what mel brooks said in Men in Tights!
since you invariably needed 11,12 and 13 to fix something.
I think BBC BASIC had "renumber", which when executed changed all those "10,11,12,13" commands to "10,20,30,40", updating the gotos as it went along
I am not a savage who would use anything beside Turbo Basic.
Oh those were the joyful days...
Level I BASIC predates Turbo Basic by a a dozen years.
I know... I am not as old as a lot of people here but I was lucky enough to encounter it before the real deal, and use to write something on 486.
BBC BASIC had "renumber", which when executed changed all those "10,11,12,13" commands to "10,20,30,40", updating the gotos as it went along
I KNOW the BASIC on Multics had that in 1973. I am not aware of a BASIC that didn't (I was writing BASIC and Fortran professionally on Multics in 1973).
And, I don't know a damned thing! I think coding is all Greek, to be honest. Maybe I could code a little if it could be done in everyday, common American English.
"Computer, I want you to set up a bunch of ships. Some are hive-minded Aliens, others are alien mechanoids, then there are human pirates, and the final faction is ME! And, we're all going to war among ourselves, with no alliances between the factions. Make it really easy to start with, then a little harder, then really hard. We'll discuss all the various weapons, armor, computers, engines, etc as we go along. Get that set up, so I can play this afternoon!"
I think coding is all Greek, to be honest.
Wrong. Many programming languages don't even accept Greek letters! :-)
Do they accept Visa?
No, only Mastercard, because it's everywhere you want to be.
You see, that's a problem. When I'm somewhere I don't want to be, I'd like my credit card to still work because I'm paying to GTFO of there.
I'm paying to GTFO of there.
Then don't rely on CC to work.
Bring plenty of good hard currency.
came up with something called COBOL
I was going to say Runaway was talking about Warhammer 40K, but now I'm intrigued by the connection between W40K and COBOL. So is the COBOL PROCEDURE DIVISION the equivalent of the God Emperor? And then by extension if Trump is the God Emperor, that means... Trump is COBOL?
Both COBOL and AppleScript demonstrate that it is possible to make a language that managers can kinda-sorta understand. It makes them feel like they are managing better.
AppleScript in particular can seem to be almost like English text. But it is not nearly so easy to actually write that way. You have to really understand the grammar to write AppleScript. Non coders read AppleScript and think they can write some of their own. Only to fail miserably. I don't know if that also was the case with COBOL.
But speaking of COBOL, it's said that Java is the COBOL of the 21st century. It's true. And for the same reason: the sheer economic value of all the enterprise Java code means that the JVM platform, and JVM languages, and even the Java compiler and language itself, will be around for a long time.
SQL can seem to be almost like English text.
Looks are deceiving.
I was writing some SQL once, working out how to fix a problem. The (non programmer) person I was working with, kept saying things like "can't you just ask it for this", "can't you just write such and so", etc.
Uh, no. It doesn't work that way. There is a very specific grammar and very specific rules. Well written code just looks like you can understand it by reading it. It is also possible to write bad code.
coding is all Greek
Ὄχι, δὲν εἶναι!
You mean Geek?
Like, code, it's all geek to me.
What's a TMB? Nothing Wikipedia [wikipedia.org] could offer looked reasonable.
The Mighty Buzzard (TMB) is SN's resident code guy, who updates and tweaks the slashcode the site is based on. My post was pure smartassery, because I don't code. TMB has never taught me anything, because I can't be assed to learn to code.
Methodology becomes somewhat irrelevant if there's an incompetent short-termist boss in charge of the project that's determined to squeeze all development time down to the bare minimum in the mistaken belief that that will save money. Most of the bugs will never get fixed. Ghastly corners will be cut. Oh and any genuinely useful code is likely to get thrown away after a year or two when reinventing the fucking wheel once again seems like the magic panacea that will bring profitability and success to their busine
You have just described every major coding project I have ever worked on
My personal workflow:Design Phase - (General idea of what the program should do, User Interface design on paper, and what tools to use. )Rough Draft - (UI prototype, partial implementation of underlying code.)Programming - (Flesh out the UI, Finish the coding.)*Beg for Artistic help - (I suck at art. Usually involves bribing the wife. Sometimes includes help with story, etc.)(Rinse and Repeat previous steps until I am pleased with the program.)Release - (Use it for whatever I'm going to, and / or send it to friends.)
This is the model that we were taught in our Software Engineering course. https://en.wikipedia.org/wiki/Software_development_process#Methodologies [wikipedia.org] So, I guess that would be top down, but I'm pretty sure I've never adhered to a particular methodology.
"Waterfall developmentMain article: Waterfall modelThe activities of the software development process represented in the waterfall model. There are several other models to represent this process.
The waterfall model is a sequential development approach, in which development is seen as flowing steadily downwards (like a waterfall) through several phases, typically:
The waterfall model is a traditional engineering approach applied to software engineering. A strict waterfall approach discourages revisiting and revising any prior phase once it is complete. This "inflexibility" in a pure waterfall model has been a source of criticism by supporters of other more "flexible" models. It has been widely blamed for several large-scale government projects running over budget, over time and sometimes failing to deliver on requirements due to the Big Design Up Front approach. Except when contractually required, the waterfall model has been largely superseded by more flexible and versatile methodologies developed specifically for software development. See Criticism of Waterfall model."
I forgot to insert Testing in there somewhere, but I guess that's the Rinse / Repeat step. Sometimes send to others to test, too.
Testing is what users are for after you've put the code in production.
Found the Microsoft code monkey.
Found the Microsoft chief engineer.
Found the Microsoft chief bean counter.
Note: Microsoft has lots of beans to count.
"I don't always test my code, but when I do it's in production"
My actual workflow usually has a waterfall phase to get to what the agile folks like to call "minimum viable product", and then there's a switch into an agile / iterative system where there are steady improvements on a working product. I'm not formal about any of that, nor do I describe that process in any great detail to my customers, I just take a new assignment with a message of "I'll have something to show you in X weeks", where X is some reasonable time frame shorter than the actual project schedule, waterfall up something that looks like what they were asking for, and then we start the iterative cycles until everybody is happy with the results. So far that's worked well.
But then again, my situation organizationally speaking leaves me largely immune from management interference, which makes things a lot easier.
That's how we roll.
The great thing about standards is there's so many to choose from!
Yup, ugly quick-and-dirty monoliths and then fix it and make it more object-oriented incrementally. You need something barely functional for tech demos if it's external, or you need shit prototyped quick if internal. Outside of designing databases (and school bullshit) I've never used even block diagrams before starting the ghetto-code.
ghetto-code, well written, is a great basis to draw a block diagram from. In my industry, there are requirements to provide block diagrams for certain aspects of the system... some I pull out of -thin air- before starting anything, others are best generated from however the code finally took shape.
my situation organizationally speaking leaves me largely immune from management interference
Unbelievable. Good for you if true, but management always manages to interfere with my group's productivity at least a couple of times a year, no matter where I work it seems.
Unbelievable. Good for you if true
3 years ago, I was the only programmer in the organization I was working for, and I was able to within a couple of months demonstrate that leaving me to my own devices would get them good results. That job was a flexible-enough contract position that I took the time to set up my own software business on the side and am now independent, with enough satisfied customers that no single customer could completely ruin me. Now that my management is me, there's really no interference at all.
You'd be amazed how far reasonable technical competence can get you when the people paying you have never experienced it before.
Sounds great, any contract work I have encountered has either been too demanding (i.e. move cross country and work on-site for 6-9 months, or local "needing" you "full time plus overtime" for an unspecified period), or too flaky and underfunded - like $10K chunks of funding without any assurances that the next $10K will be available regardless of the results produced. The time I might have built a multi-customer base like you describe, I was in a University town and all the businesses were working on the expectation of getting lucky and hiring "great kids straight out of school" for the price of incompetent fresh-outs. I actually interviewed with one shop where the manager came to a point and said: "O.K. - I want you here, next question: what are your salary expectations?" I told him what I was currently making, he nodded and told me that he was the highest paid programmer there and he made half what I do... and that I should look to another nearby city if I wanted that kind of money - advice I ended up following within a couple of years.
Good for you if true, but management always manages to interfere with my group's productivity at least a couple of times a year, no matter where I work it seems.
Depending on what your floor for "interference" is, sounds fantastic.
I'm pretty happy where I am, not looking to move. I have definitely been in worse places.
That's not necessarily a bad thing. I've had days where someone interrupting my coding to tell me the building was on fire and I needed to get to the nearest exit would have had me wanting to choke them. This isn't an especially rare trait in code monkeys, thus management.
Some people get their dopamine from sex, some get it from adrenaline, or drugs, or pay-back / power tripping,
Code monkeys get it from converting concepts into working code.
They knew they had to start teaching the computer in 1982, but they didn't really know how to go about it. They bought some and told the science teacher to wing it, he read the textbook and made up some stuff. The semester project was an elaborate BASIC program to convert numbers in one of a few bases to their representations in another base. Like binary, octal, hexadecimal and decimal to any of the other bases. He outlined a menu driven structure to select the source base, then for each source base a menu to select one of the three destination bases, then a collection of 12 base to base conversion routines to get the desired answer.
Just to be a jackass I wrote a 3 line program that converted any base to any base, in the same language on the same machines as the class. I used a logarithm to predict the length of the result so I could imitate the formatting he specified - that made him feel better because he couldn't expect his students to understand a logarithm.
I used a logarithm to predict the length of the result so I could imitate the formatting he specified
Do you mean algorithm? I'm confused.
Log base N is related to the number of digits required to represent a given number in base N.
Don't feed the trolls
1st experience - borrowed Z80 hooked to TV. Totally clueless 16yo.
2nd experience - COBOL coding sheets, Nashi-Schneidermann diagrams and top-down design.
Then I went to college. They had that year redirected two senior statistics lecturers to birth the CS Dept. We learned about PL/1, BASIC and a bunch of theory. PCs were a new thing. The lab has brand new rows of TRS-80 machines. Some of us rebels discovered a Pascal compiler on the VAX. Learned to code efficiently as you got ONE second of CPU. Final year we wrote a "compiler" for a theoretical language. Five years later this big Compiler Project had grown into creating a mini-C compiler (by which time I was long gone).
Then I got some jobs and REALLY started to learn...
For a couple decades the methodology I used was
Client asks for XImplement what client actually needs which is YClient makes dozens of changes and insane demands now asking for Z which has nothing to do with X or YCollect paycheckGOTO line 1
Programming is the kind of job where you'll have an eight hour whiteboard interview on the topic of B-trees vs red-black trees and compiler lexical analysis theory to get a job, where your coworkers don't understand the difference between a word document and a database.
I wish I could mod you up further.
Manager: how many unknown bugs are there, and how long will they take to fix. I need to know by tomorrow morning.
Do what I do to fix bugs - wrap everything in a giant try block followed by an empty catch block. Your program will continue working like a charm, if your customer doesn't care which places the decimal points go in his payroll system.
I have no words.
Yes. I do. Don't do this in powershell. Try doesn't always catch clean which can result in broken program.
I don't know if you are serious, and I hope you aren't.
But, I am sad to say I have seen this behavior in legacy code my team has had to maintain. When I asked devs who had been here a long time why there were so many empty catch blocks in the code, they said former management wanted to reduce the amount of errors the service produced, and gave a ridiculous timeframe to get the work done. The only solution was to remove the logging statements in the catch blocks. This is a true story. :(
Please don't work on anything important in the real world.
how many unknown bugs are there, and how long will they take to fix
A wise man once said:
Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones.
There are also the swept-under-rug knowns. Eventually that tiny bump in the carpet becomes big enough to trip over making it a don't-trip-over-the-imaginary-unknown.
Ugh, what a complete lack of proper flow control.
X = Client.last_request()
Y = Client.actual_needs()
Z = Client.last_request()
assert X != Y != Z
Back in the 1970's . . . they covered both top down and bottom up approach.
As I got into Pascal, the emphasis was more about data structures than either top down or bottom up. The popular saying was: "Once you get the data structures designed right, the code almost writes itself." I largely found that statement to be true.
But one must remember the primitive state of computers. Less an 1 MB of memory. Often shared among several users.
Back then, what you would think of as a large design, is something I would think of as a drop in library in to a modern software project.
It is amazing how much more sophisticated software is today. It eats up all available memory and processor resources. But it does so much more. Compare, say, a modern e-mail client to one from the early 1990's. Html. Spell and grammar check interactively. Or compare development tools. Interactive compilation. Code and syntax awareness. Refactoring.
I would say today at a ten-thousand foot view, you do top down design. Really overall organization. But down in the weeds of the coding of individual parts, bottom up approach also has its merits. You often know what you will need at a higher level and can begin coding low level functions, and working your way up.
So maybe there is this "meet in the middle" approach where everything just comes together.
"Well, this oughta work."
"Dammit, why did it do that?"
"That's funny. It's sorta useful for another problem I'm working on..."
Sure go ahead learn to program. It does not matter which methodology you use. The end result will be the same. You will be jobless no matter how much code you write.
There are NO JOBS for programmers anywhere at all. Do not believe the deceitful lies of shysters like Michael David Crawford. There are shittons of fake job postings on job boards and exactly zero jobs. Michael David Crawford is a fucking asshole who sells false hope to desperate destitute losers.
Depends on what you program. Plenty of jobs for CNC programmers. If you can do three or more of horizontals, five axis, Swiss, mill-turn, and macro B, you can just about write your own paycheck.
Heh :) Damn right.
Likewise, if you can take a MS Access Database and make it do anything you want, you have some income believe it or not. Plenty of small businesses, and entrenched platforms in medium to big businesses, have some sort of MS Access nightmare. Although, I love it. Very neat and self contained database, that can be *greatly* extended by a simplified VB, with WYSIWYG development of forms. It wasn't all that complicated to connect the forms to data with a gui, or write code in VB to connect to whatever other databases you want. I digress though, my point was that it was a pretty awesome program. You can imagine how many different places it is still in use, and for whatever reason, the system cannot be upgraded, there is no alternative, and somebody has to get it working again.
I wouldn't put all my eggs in one basket of course, they will eventually be upgraded, but there are more than a few industries where this work still exists.
I know for a fact this is incorrect. We are actively hiring SDEs. And so are most other tech companies in our area. And we aren't in CA/SanFran where they are hiring anyone with a pulse.
There ARE jobs for people who ACTUALLY know how to program.
Those offering jobs have become much more careful at hiring because there are hoardes of wannabe, lazy, incompetent, cut and paste off the internet programmers trying to get those jobs.
Bottom-Up and Top-Down go well with Step-wise Improvement. I Use-Modify-Create the aforementioned to create a combination of the above to meet my needs. I learned it at all by myself.
This is interesting because I actually teach programming. Both Bottom-Up and Top-Down are impossible for beginners to understand by my experience. The amount of discipline required and foresight into where you are going is severely lacking in beginners.
I start with Use-Modify-Create to have the students get a "feel" what a program is. Let them play for a while. The examples used are always very simple and some indications are given what to do next. They continue with (highly supervised) Stepwise-Improvement once they have some rudimentary feel of what is written (without any knowledge of details). Stepwise-Improvement is superior in showing very small steps and the phases in which a program is developed. This is where you start adding terminology, the structure and meaning of programming. Stepwise-Improvement is particularly good at showing the iterative process of development.
Once that is over, both Bottom-Up and Top-Down methodologies are touched onto by using specific examples of which may be applicable. However, most will never create a large enough program to require this much strict methodological structure. Also, the common organizational development methods are covered like "lone wolfs" and Agile (in many forms and derivatives) and how to do proper cooperative development (and using revision control).
Most students seem to respond very favorably to this approach.
I was going to say something similar. I was taught to program in the early 1980s. At that time we were taught that you solve a problem (i.e. design the code) in a top-down fashion, but then the code is written bottom-up. Each module is tested when written and eventually you end up with a working solution that meets the design requirement.
I learned in the early 60's. Recommended methodology was flowcharts and GO TO statements.
I read the Algol 60 report and yearned for something better than early Fortran. Then we got a new compiler and could have nonrecursive SUBROUTINES but still no IF THEN ELSE.
Even Fortran 2 had IF with both then and else.
More than that: IF (N) did different things for N < 0, N = 0, and N > 0
It is true that you did not get recursive subroutines even in most versions of Fortran 4.
Unlike Algol 60, Fortran 4 was not invented in 1904. It just seemed that way.
Algol 68 is still the best. Take your Python back out into the desert where it belongs.
Writing the code out onto a keypunch form, and making sure the cards stay in the correct order. Inserting ad hoc fixes into the middle of the deck. Etc.
OTOH, I missed patching binary decks. YAY!!
I don't know why the last option (self taught) is exclusive from the other choices?
Even if you are self-taught, you will have taught yourself to work bottom-up, top-down, etc.
You may not have the education to know you're actually working bottom-up, top-down, etc. You're just 'doing what works because that's how you learned to do it.'
may not have the education
This is a lot of what I learned at university, and also in later continuing education: labels to put on the things I already know so I can explain them to other people in terms they will recognize, maybe even understand.
programming is still a thing? jesus, its 2018, not 1958.
Of course - you can always use a framework that will give you a 20Gb program that prints 'Hello World' and hides numerous vulnerabilities that can be maliciously exploited.
Which prompts me to also ask, what do you call the process of writing the code that implements the framework?
Copy and pasting from Stack Exchange.
a framework that will give you a 20Gb program that prints 'Hello World'
Only 20GB? - its time you clicked on that "Software Updater" popup. Most of us are up to 44GB now.
Yeah, I know, today people don't write programs, but apps. But you know, "apping" just dousn't sound that nice. :-)
I don't know if you're trying to be funny or are just stupid.
If this poll had an option for "other", I'd fill in "Copying and pasting verbatim examples (such as from stack exchange) and tweaking them until they work", an actual primary approach that I have seen among university students that I have tutored.
I say that like it's a bad thing, but I have done the same thing myself a time or two, but with a different goal in mind. The student seeks to fulfill an assignment and move on; I was seeking to get something working and then take it apart to see how it works and how I can do that again in the future and how I can adapt it to various projects and the other various "how" questions.