Slashdot Mirror
'Here Be Dragons': The Seven Most Vexing Problems In Programming (infoworld.com)
InfoWorld has identified "seven of the gnarliest corners of the programming world," which Slashdot reader snydeq describes as "worthy of large markers reading, 'Here be dragons.'" Some examples:
- Multithreading. "It sounded like a good idea," according to the article, but it just leads to a myriad of thread-managing tools, and "When they don't work, it's pure chaos. The data doesn't make sense. The columns don't add up. Money disappears from accounts with a poof. It's all bits in memory. And good luck trying to pin down any of it..."
- NP-complete problems. "Everyone runs with fear from these problems because they're the perfect example of one of the biggest bogeymen in Silicon Valley: algorithms that won't scale."
The other dangerous corners include closures, security, encryption, and identity management, as well as that moment "when the machine runs out of RAM." What else needs to be on a definitive list of the most dangerous "gotchas" in professional programming?
1 who's my customer 2 What does he or she actually want.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
Cowboy programmers really hate that.
“Common sense is not so common.” — Voltaire
Oh christ if I get one more node.js developer claim that node is multi threaded...
http://michaelsmith.id.au
1. Anyone with money
2. Everything
Next!
2 Developers who decide to reinvent the wheel because "They know best". (Just dealing with code where somebody decided I don't want to use the built in stuff, I'm going to do my own date time stuff which constantly has issue. Makes you pull your hair out.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
C'mon. Threads -- I concur wholeheartedly. But closures? Granted, you have to wrap your head around them, but then they are a docile workhorse.
As for threads... don't unless you have to. You add the benefits of concurrence and common address space and multiply their curses.
Buffers seems to cause a lot problems, particular when they overflow. As a non-programmer (well, a very long time ago programmer) I've never grasped why preventing overflows seems to be so difficult.
Surprised all of them weren't just "Seriously? I've looked like 6 times, I don't see a missed semicolon. I think the compiler is just lying now."
I'd like to second that #2 problem you mentioned. Easily the most annoying problem in programming I face is functional requirements not being fully specced out before the project begins and discovering well into it that I have to redo a month's worth of work when the requirements exceed the demands of how the code was originally written. In most cases, time is usually given for these changes, but sometime's it's not... and man, are those times infuriating.
File under 'M' for 'Manic ranting'
As far as I know, there are four hard problems in programming:
1. caching
2. naming (i.e. how do I name that variable/method/class)
3. off-by-one errors
people are by nature flawed and some chained by hubris. Creating software can inculcate a self perception as someone with higher insight into patterns and abstract thoughts. Problems occur when that self perception exceeds known reality.
And it's not that hard. Some people make it hard because they're incompetent. The golden rule of multithreading is: your multithreading set-up has to be very simple. Don't optimize (and for the love of god, unless you really understand cache coherence, don't use atomics), aim for clarity, use mutex locks for shared data, and if you have to use several, make sure you acquire them in the same order. 99.9% of the problems disappear if you follow this simple advice.
Seriously, i spend more time thinking on this than anything else lately.
1 who's my customer
2 What does he or she actually want.
What you mention are not programming problems.
Haha, you should be more Agile! It's not Agile to find out what your customers need first. Just throw a bunch of shit at the wall, make it flatter, and dump it into production to let your customers do your testing and chip away at the things they complain about.
They'll definitely give you useful feedback and not switch to another software product instead. If there's one thing that's always been true about customers, it's that they're fiercely loyal to their software vendors.
Script kiddies spent their whole fucking lives in Javascript are terrified of threads...just like they are of Trump. All good software is multithreaded. All useful software is multithreaded. Threads have been around for fucking decades. Just because ppl got all chicken shit and decided to go all "single threaded non-blocking V8 engine jackoff" means squat. If you can't do threads you suck as a programmer and should either work really hard to figure it out or find something else to do.
> NP-complete problems. "Everyone runs with fear from these problems because they're the perfect example of one of the biggest bogeymen in Silicon Valley: algorithms that won't scale."
Customer: Why is this problem not scaling?
Programmer: It is NP-hard we are basically just brute forcing it.
Customer: If you can't solve this "NP-hard" problem, then I'll just find someone who will.
Programmer: Sure, let me know when that happens.
Multithreading's issues in particular are a matter of education, not technology. The rest are related to programming only vaguely; in particular, NP-completeness is mostly a CS thing and very rarely encountered in software engineering.
3 : It has to be ready 2 weeks ago so we'll forward that untested alpha version to our high risk clients who will sue the fuck out of us if anything is not right. 4: Oh can you make a feature that does X for client A. I'll be here for another hour. 5: assumes input from external program is correct by glancing over the xml of 1 example record. 6: we will make that split between a development version and a stable version when all the features on the list are done. (read in 4 years) We want the new features out as quickly as possible. etc....
with some proper study of functional and parallel programming
Yeah but for every person who does that there are 10000 wannabees who just want a bigger paycheck.
http://michaelsmith.id.au
Re: Serious he missed the 2 biggest problems I've h
Arbitrary truncation of data...
In my experience, data and operations tend to fight duels - often to the death! Sometimes on horseback with 10 foot lances, sometimes not. Its all good fun - if you are hiding behind the servers and peeping though the gap where the backup drive should have been!
--
I can't remember if I voted for Trump, but I definitely voted for weed!
There's not much difference between data and operations in abstract math; polymorphism/dynamic dispatch is independent on the notion of classes; and compile-time issues have been solved by Lisp and the ability to do anything at any time (run code at compile time or compile code at run time).
Ezekiel 23:20
Modern SAT solvers are able to solve SAT problems with millions of variables in seconds. Yes, there are hard problems with some hundred variables that are too hard to solve. But as it turned out, most useful problems are easy to solve. So if you have an NP-complete problem, you should just try to put it into minisat. If it can't be solved easily, there's still time left to despair.
Closures have been a part of programming since LISP
Since Scheme, I believe. Lisp "at large" tended to be dynamically scoped before Scheme, with predictable (deleterious) results. The improvement was so substantial that this was one of the novel things adopted in the Common Lisp standard, beyond the "lowest common denominator" unification of extant dialects.
Ezekiel 23:20
1 who's my customer
2 What does he or she actually want.
What you mention are not programming problems.
I am a programmer and I deal with these two issues way more than any problems with multi-threading and NP-completeness. Multi-threading isn't that hard if you have some experience and a good library. NP-Completeness is more of a math problem than a programming problem. For programming, there is no optimal way to do NP-complete, so you just use a heuristic for a "good enough" solution.
Dates, including time zones and daylight savings time. Constant source of bugs.
For example I worked on code where the guy decided he could use a Boolean (yes in C/C++) for thread synchronization. (Just no, please.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
Writing performant code without obscuring the algorithm or introducing CPU / OS dependencies that will break when you port it.
Writing code that understands cache coherency and is structured for memory locality.
All those moments will be lost in time, like tears in rain.
data and operations are duals
In my experience, data and operations tend to fight duels - often to the death! Sometimes on horseback with 10 foot lances, sometimes not. Its all good fun - if you are hiding behind the servers and peeping though the gap where the backup drive should have been!
Thus spake the master programmer.
Socialism: a lie told by totalitarians and believed by fools.
Seriously. I've worked in many departments for many different employers and seen many different reporting implementations. All of which have been different. All of which have been terrible. Layers and layers of impenetrable abstraction over some "generic" "engine". Every. Single. Fucking. Time. I swear it's the same person.
I had a dream, bright and carefree, but now there's doubt and gravity
Only if you think you can apply Agile and 2 week sprints to *everything*, including the "thinky parts". What that leads to is incomplete software architecture, and class / data models that do no cater well to all use cases => nasty refactoring. I found that in a lot of software projects I participated in, as well as my own projects... I am a terrible cowboy coder.
However, I've had a few projects that have been very well designed from the get-go, with a thorough design that stands up to chaning requirements. Agile is a perfectly fine approach to develop or extend that kind of software.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Closures are not a ``problem''. Ignorant or incompetent implementations of closures is the problem. ...
Just as ignorant or incompetent implementations of garbage collection and memory management is a problem.
And ignorant or incompetent use of arrays/vectors/buffers and pointer arithmetic and access permissions and
So here is an alternative list:
1. Low-skilled programmers (``script kiddies'') who write profound amounts of buggy code.
2. Low-skilled language ``designers'' who re-introduce the known bugs of the past and introduce new innovative bugs as well.
3. Low-skilled managers who reward high output over high quality, thus ensuring an on-time, under-budget hairball and bugs nest.
4. Low-skilled educators who teach ``coding'' rather than computer science, thus ensuring another generation of the above.
5. Low-skilled professional organizations who reward and encourage incompetent industry leaders to unduly influence the field.
6. Low-skilled investors who reward incompetent technology from dominant, monopolistic companies.
7. Low-skilled consumers who flock to buy flash-in-the-pan shiny stupid gimmicks but won't invest in sound technical innovation unless it's flashy.
This is why C students should never be allowed to graduate w/ a degree. They only go on to further muck up the world. Color me bitter. ;-)
P.S. That `C' above refers to grade level / professional competence, not the language (which should really be named D or D minus minus). *smirk*
Error: NSE - No Signature Error
Yes, this. the threading comment struck me more as indicative of an amateur in the area than any real flag of a problem area.
if you understand threading, you can work just fine within it, do appropriate things, don't do inappropriate things. You also have to understand the problem you're trying to solve, but again, that comes down to your skills - not any inherent "Dragon-ness" of threading.
I thread the heck out of my software. Works great. Cross-platform, too. Relatively easy stuff - image processing - and really hard stuff, real time signal processing where all manner of stuff is happening concurrently that depends in one way or another on the other stuff that's happening concurrently. I'm not talking about some thread off doing network management, either.
For me, it's strictly a matter of not going in there casually and carelessly. The appropriate planning and thinking - IOW, design first, then write software - pays off every time.
Of course, if you treat threading casually (as with many other things), it immediately becomes a footgun. Well, that's why Darwin gave us multiple feet, sonny. :)
But the whole point is we're supposed to be good at this. You have to pay your dues to get there. Programming Javascript on a web site isn't going to build the required skillsets.
I've fallen off your lawn, and I can't get up.
I mean floats are scientific notation on a computer with sig figs and such. That's stuff I would expect physicists (and chemists) to be experts at.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
...compounded with "I know it'll work, I'll just build and ship, THAT doesn't need to be tested!"
I've fallen off your lawn, and I can't get up.
I think you mean "memory consistency".
Reminds me of my last job.
Boss: this isn't what I wanted, did you read the spec?
Me: you gave me a ticket that had 3 sentences in it. That's not a spec.
Boss: that is too a spec. Go back and read it.
Me: this leaves a ton open to interpretation. This isn't a spec. You need to clarify this with a lot more detail.
Boss: come on, you knew what I meant.
And that's partially why I quit.
If you understand pointers and malloc(), you can work just fine within them too. But that hasn't stopped people from disparaging them relentlessly and trying to come up with new "safe" languages that don't have pointers and memory allocation.
Added irony: With pointer and memory allocation bugs, the problems are at least reproducible. Can't say that about threading bugs.
still cannot figure out why the Java developers thought they needed to do away with pointers and (application-controlled) memory allocation, but then turned around and encouraged the use of threads. It's kind of like saying to children: "Don't play with those scissors, you might cut yourself. Use the power saw instead!"
You don't tackle NP-completeness challenges. NP-completeness challenges tackle YOU!
I've fallen off your lawn, and I can't get up.
NP-Completeness becomes a programming problem when the people who do the programming cannot spot a NP-problem and then spend countless hours to beat it.
I am a programmer and I don't deal with it more than common sense requires me to.
I have a boss, that's his job. He is better at dealing with customer demands, I am better at programming. That's why he hired me, and that's why I prefer this to being self employed.
LISP doesn't have closures, at least it didn't back when I learned it, it had dynamic binding, precisely what will shoot closures dead. Scheme had/has closures.
> Writing performant code without obscuring the algorithm or introducing CPU / OS dependencies that will break when you port it
That can sure be annoying. I hate writing stuff that's much slower than need be, and I like it to be clear.
Fortunately, 90% of the time is spent in 4% of the code. For the other 96% of the code, performance really doesn't friggin matter. I like performant code because it's beautiful. And it doesn't matter. Unless it's the roughly 4% of the application where it does matter, performance (1ms reponse rather than 2ms) is purely for my own enjoyment. Therefore I must be willing to let go of that when it conflicts with other priorities.
I would like to add a small list:
1. Cloud billing, yes just try and figure out your AWS cloud bill.
2. Race conditions (but technically this is a multi-threading problem).
3. Database Deadlocks, yes I know most RDBMS try to resolve deadlocks but they still happen
4. Semaphores / Spinlocks and Deadlocks
5. BIOS insecurity, yes you can decompile an EFI bios, change it, and reload it back on a motherboard
6. Firmware/Hardware security and trust issues with Intel CPUs, USB devices, and expansion cards. No hardware is secure thanks to the cesspool of firmware and rowhammer.
7. New data breaking old programs, such as unicode characters
8. The incredible pace of obsolesce in hardware, software
9. Windows 10.... who the hell knows what the O/S is doing? Sit and watch task manager on a fresh install for 30 minutes and you will be amazed at the stuff that goes on, Windows Telemetry anyone?
10. Apple removing legacy ports from hardware and encouraging everyone else to do the same so we all end up in dongle-hell.
I just started doing some work with "communicating sequential programs" from 1978, in the form of pipes inside a language. Gee, something we know works, that was ignored by everyone but the Unix folks for 33 years.
Blech!
I now plan to create a time machine and go back and kill the unrestricted-multithreading folks (;-))
davecb@spamcop.net
It's not arbitrary it's becau
Seven puppies were harmed during the making of this post.
All of the "vexing" problem boils down the same thing:
Programmers who never learned computer science, and think doing their job is HARD.
Heptapods enumerating software issues using their tentacles.
Have gnu, will travel.
I wonder how much of this is pre-C99 code, where there wasn't even a dedicated type for 64-bit integers, or pre-x86-64 code, where use of 64-bit integer calculations in an inner loop caused slow subroutine calls to a 64-bit arithmetic library. A double has more precision than an int32_t, or in the case of pre-C99, whatever integer type a particular ABI guaranteed to be 32-bit.
I've never understood why programmers have problems with threads.
Having to code for a platform that lacks a worker thread library might be part of it. Until very recently, neither the C standard library nor the C++ standard library supported threads. Not until C++11 did C++ gain any sort of threading support intended to work across both POSIX and Microsoft Windows. And even nowadays, the C++ compiler already installed on a particular system isn't guaranteed to implement C++11 let alone C++11 threads, and cross-platform threading on some platforms thus costs 245 GBP per developer.
Put everything in one huge massive universal class of doom. Kiss refactoring goodbye!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
For resources other than memory, all languages require it, so you might as well learn to program.
I think the traditional argument is that allocations of memory outweigh allocations of resources-other-than-memory by orders of magnitude, to the point where one feels justified in making allocation only of memory a language feature. Then your unit tests need to test only correct allocation of resources-other-than-memory, not of memory.
Rust developers would then ask why you can't have both speed and safety.
Because innocuous typos can still produce legal (but very incorrect) programs.
But more generally, there's a tension between some people's need for conciseness and other people's need for assurance that the program actually does what the author intended. And that's closely related to the tension between ease of creation vs ease of reading/understanding/change.
NP-Completeness becomes a programming problem when the people who do the programming cannot spot a NP-problem and then spend countless hours to beat it.
To be honest, it's often the programmers who hear "optimally solve it" when the requirements actually are "sufficiently solve it". For example I just suggested for a knapsack problem at work we use a simple overflow algorithm instead. It doesn't matter that we're not perfectly sizing the chunks as long as they're below the max size, it's like a 10-20% deficiency on a 50-fold improvement. Sure with infinite time and resources we might have done it perfectly, but really it's just a workaround for limitations in another imperfect system. And particularly when it comes to any human scheduling, were it often turns out that there are some unsaid requirements which means they'll look at a time table and say this won't really work anyway.
Live today, because you never know what tomorrow brings
Easily the most annoying problem in programming I face is functional requirements not being fully specced out before the project begins
This is one of the most fundamentally misunderstood problems in software design. Probably because it is not really a software problem at all, but a business problem, and the solutions require intelligent business decisions which seem to be beyond everyone.
The solution to the specification problem is not more detailed design specs. The reason is simple. The people writing the detailed spec are not the people using the software, and they are not the people writing the software, so they are in no way competent at providing communications between the two. All of the successful software designs that I have seen are the result of competent programmers becoming involved in the completion of a task that software automation would apply very well to. Those people then subsequently write the software applying their first-hand knowledge of how the software will be used, and what the users needs are.
If you want your software to be very well designed, sit the programmers down to perform the job of the people who will use the software. They need to become proficient at this job, so a 1 week training course aint going to cut it. You need them to spend at least a month doing the job.
If you have the software developers do this, you will get exceptional results without the need for any kind of specification, or other real involvement, because the programmers are naturally very good at optimizing processes, otherwise they wouldn't be good at programming at all. The client gets the features they need, want, and didn't even know they could have. The software design itself is cleaner and faster because the developers have a fully fleshed out idea of what the software needs to do, and can design to meet the need instead of designing to meet a spec that may or may not remotely resemble what is feasible , practical, or correct.
I wish I had a good sig, but all the good ones are copyrighted
Added irony: With pointer and memory allocation bugs, the problems are at least reproducible. Can't say that about threading bugs.
Sounds like you never had to debug a use-after-free bug.
Years back, a telephone switch company made a three-line change in some exception-handling code and pushed it without testing. Somewhat later the exception happened, was handled improperly, and the problem propagated from one switch to another, eventually taking down long-distance phone service for most of the East Coast. Ultimately put the company out of business.
Absolutely one of the hardest programming problems is in distributed real-time systems, making sure that errors are caught and damp out rather than propagating.
Some people, and programming languages, force OOP where it doesn't fit or isn't needed. One example being langauges in which ints are objects. That's silly.
On the other hand, for GUI design, the idea of a GUI widget as class, with each form field having field.value makes perfect sense. Radio_button and check_box being subclasses of widget is a great idea.
There are many systems for which object-oriented programming does not make sense, and many for which it does. Much like a screwdriver is very much the wrong tool for nailing shingles. Throwing out the tool entirely costs you significantly. If you never use OOP because you're really missing out, and working too hard. Much like a handyman who threw the screwdriver in the trash when he found out it wasn't good for installing nails.
Haha, you should be more Agile! It's not Agile to find out what your customers need first. Just throw a bunch of shit at the wall, make it flatter, and dump it into production to let your customers do your testing and chip away at the things they complain about.
I know you're just trying to troll, but that's actually what you have to do sometimes.
The problem is that those specs your analyst gave you isn't what the users want (even if they are complete). What the users told your business analyst isn't what they want. The reason is that users often don't know what they want. Users know what they have done up until now, and everything they ask for will be framed in the context of what they have been doing all along, especially because they'll frame everything as a solution rather than a set of problems and goals. Often, the users have no idea you can transform their experience into something better because they don't know technology like you do.
Instead, you need to sit down with some users and get a grasp of what they need to accomplish. This should be done both before and after you put some software in front of them.
The rainbow series of books lay out all you need to know about security. Just study them, and you'll do just fine, as long as you don't network anything. ;-)
I was taught, for a spec to be good, you could give it to two different developers and get the exact same result. Otherwise, you need to improve the spec.
You have a 20 year old AS/400 system with millions of customer records using hand-typed-in data that needs to be correlated on a new system. Company names, customer names, addresses, routing numbers with variable use of dashes, periods, part numbers, account numbers, prices with variable decimal places, etc...
Not a strict programming issue per se, but an issue that is expected to be solved with programming, with extremely variable results.
My Other Computer Is A Data General Nova III.
Well, that's because Agile is not supposed to solve technical issues like architecture or data models. It's supposed to help software development efforts track changes in organizational priorities and incorporate things they learn into their plans as they learn them.
If you rely too much on any methodology it's not going to work.
I have often thought the most important quality a software developer has to have is caring about the people who will be affected by their work. If you're only interested in technology you'll find an excuse to use the latest thing. If you're a prig about methodology you'll end up going through the motions. When you care about your users you'll always find a way to not let them down.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I found it for you.
Ezekiel 23:20
One of the biggest, most vexing problems in computer science is newbies who equate basic programming to the hardest problems of the field.
OK, I realize this is arcane. Let me give an equivalent situation in, let's say, agriculture.
Farmer: "OK, young intern, today we'll learn how to water plants!"
Intern: "Waaaaah! This is as hard as the manipulation of space-time with thought alone!"
Farmer: "...Grab a goddamned watering can, moron."
Multi-threading when you're sharing memory space is pretty easy.
Efficient distributed computing with locks, shared state, transparent failover, etc. between separate computers is non-trivial. Hats off to those who get it right.
I meant what I've written. Read up on MESI protocol. It's all about cache coherence.
And, he's right. Atomics have nothing to do with cache coherence.
Never underestimate the bandwidth of a 747 filled with CD-ROMs.
I got 98.99999999 problems, and a float ain't one......
HA! I just wasted some of your bandwidth with a frivolous sig!
Dammit, 30 seconds after posting that I realized it was even better as... I got .99999999 problems, and a float ain't one......
HA! I just wasted some of your bandwidth with a frivolous sig!
If you recall that when programming courses teach about code, they never tell you what reasonable assumptions have to be made.
For example, write a program that computes the profit, given sales and cost. Is there a tax? What is the number of digits for input value, output value, what should be done if there are errors in the data and so on., are never ever discussed. So, multiple solutions appear but the instructor is mad that he did not get what he wanted.
Had he worked say, in a restaurant, he or she would know the details. The observations here are valuable.
Reminds me of my last job.
Boss: this isn't what I wanted, did you read the spec?
Me: you gave me a ticket that had 3 sentences in it. That's not a spec.
Boss: that is too a spec. Go back and read it.
Me: this leaves a ton open to interpretation. This isn't a spec. You need to clarify this with a lot more detail.
Boss: come on, you knew what I meant.
And that's partially why I quit.
So you didn't ask your boss what he actually wanted before you started coding? You didn't ask for clarification for each ambiguity you discovered during coding? You just shat something out at random?
Socialism: a lie told by totalitarians and believed by fools.
And until you do, please don't embarrass yourself in public voicing your opinion on topics you don't have a foggiest clue about.
http://www.puppetmastertrading...
I agree. These problems are something my architect brother spoke about. His way to deal with it was to listen to what the customer asked for and then come back with three options for them.
The first is give them EXACTLY what they asked for. If they wanted a staircase to nowhere and a conversation pit in the garage then that's what they'd get. The second option is to offer them what he thinks they really wanted. Some people just don't know what they want but with experience my brother could get an idea of what people liked and needed. The third option is he'd give them what he wanted to make. He'd take their input but then come up with something he'd find interesting or would like to see experimented with. He said few people would take his first option.
I've also seen this in healthcare. People complain about how hospitals and their staff do things among other complaints on how they are treated. I can trace many of these complaints to a single cause, they are not the customer. The insurance company is paying the bills and so they are the real customer, and many of those in healthcare know this. This then creates a problem because the patients will not complain to the insurance company because they don't realize that their "customer" is not the hospital, but the insurance company. This is why I fear government healthcare, it adds another layer in this chain with one of them being the people that brought us the DMV and the poor customer experience we've all come to know from it.
That's not exactly where I intended to go with this but it is where I happened to end up. As a "customer" of government healthcare through the VA I can tell you that is not where you want to be. I will say that VA care has improved but it only took people dying of negligence and suicides for a enough US Senators to notice and care enough to act.
I am armed because I am free. I am free because I am armed.
This guy is a massive supporter of frameworks as somehow a good idea. This guy is clearly someone fresh out of school or works for the government. I would say to that, all frameworks are easily the #1 thing keeping me employed. Frameworks are great if you are making a restaurant website, or an app that tells people what the upcoming plays are at your little dinner theater. Organization after organization take on a big project, One of their geniuses pulls out his favourite framework, and poof 90% of the project is done in less than a week. Then for the next two years (with an original schedule of 6 months) they are putting out shaky crap that is missing critical features, breaks all the time, and takes any new developer months to get a vague understanding of what the hell is going on.
Basically the framework is great if they are doing what the developers of the framework intended. Stray 2 feet from their intended sidewalk and you are now walking in the middle of the road. It takes bandaids, restructuring, tunnels, and magic to get to where you wanted to go.
It is much harder to, instead just choose one or more great libraries, and then handcode the whole thing into existence. Harder at the start, not harder in the end; they key being that you get to the end.
This guy has another article that talks about 9 bad habits that programmers love. One was using "goto". Nobody uses goto. Nobody in any modern programming language, doing anything modern in any way at all. Maybe there is someone who ported QBasic to android and they are using goto. I have yet to meet someone who doesn't use "goto" as the measure of a fantastically crappy programmer.
There is nothing wrong with multi threading. ;D just nitpicking :D .Net world. ... and under my watch I let no one waste his time with that either ;D (it is just as I pointed out above: mental masturbation)
And languages that support it of the shelf with language constructs and a sound library are obviously easier to handle than raw C or assembly.
still cannot figure out why the Java developers thought they needed to do away with pointers and (application-controlled) memory allocation, but then turned around and encouraged the use of threads.
That is a rather silly comment. First of all "Java Developers" are not the language designers or developers of the Java Virtual Machine, at least not until Java 1.2 or 1.4 came out.
But to answer your curiosity: why the fuck (sorry for the language but it is appropriated here) should I waste my time with mental masturbation and allocate and deallocate my objects manually? Just to show of to my coworkers: "see! what I can do!! A Bug free manually memory managed application! Suck it you losers!"??? In a typical C program, a programmer needs about 30% of his time to get malloc/free right. In C++ with all the new features you can reduce that greatly. However: they only introduced all those new features when the realized how productive Java/C# and friends is.
On the other hand: why the funk should I code an application that will run on a multi core system single threaded? When I have a language where doing multithreading is close to trivial? And keep in mind: in my country universities still teach how multithreading works in the 3rd or 4th semester if you study computer science. But I know: you live in a country where "programming" is neither considered "science" nor "engineering"
Note: I never had a bug in a Java multithreaded app by wrongly used language/library features, and I can't remember one where there was a conceptional bug regarding MT itself.
In modern Java programming you should rely on the libraries anyway, and let the experts (stream library e.g. or Spring etc.) do the "hard work". I'm sure the same is possible in the
I rather spent my time with architecture and business requirements than fiddling with pointers and primitive thread constructs
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The title of this message is originally "1&2&3&4&5&6&7&8&9&0&1&2&3&4&5&6&7&8&9&0&1&2&3&4&5&".
I can't type another character into the title box.
It all shows when I hit Preview, but I won't know if it makes it until I hit Submit.
If you think I voted for Trump because of this post, you're wrong. I voted for Dr. Jill Stein of the Green Party. Again.
There are many excellent points here - and as a programmer since I was a teenager and also in my 50s now - I have also thought about this problem a long time.
A good visual analogy to a computer system is Russian nesting dolls. Each doll can be equated to an underlying system and associated languages. At the deepest innermost layer you have microcode - running on an extremely simple state machine that has code written for it to emulate a Von Neuman central processing unit (CPU). Next comes binary numbers that can be inserted into registers and memory using the CPU. Up from that is assembly language - which is another extremely simple langauge used to communicate with the CPU in native binary. Above that are a plethora of compiler based languages - that essentially convert their human understandable grammars into native binary (or intermediary assembly language - and then to binary...details). At the same level there are also interpreters - which are interactive languages that can be programmed 'on the fly' one line at a time; each line is acted upon immediately when you enter it - and were used effectively for teaching students... Basic being one such language. They could also be used for high performance computing - LISP being an example. It's important to point out at this point - all languages don't have to be loaded on a given system - these are just the possibilities.
Now things get really interesting: virtual machines. A virtual machine is a simulated CPU that has its own simplified instruction set that an applicable language can compile against. The nice thing about a virtual machine, is it can be deployed across many different hardware architectures without the need to recompile your programs. Examples are Java's JVM, Python's virtual machine, and Javascript V8 virtual machine.
Finally you have application frameworks - collections of libraries and other functions that allow you to quickly build applications with less work - because most of the heavy lifting is already done for you. In this category I would also lump code generators - like the Unified Modelling Language (UML) - that has tools which takes a program defined using the UML language - and generates code in a specified programming language.
There are far more complexities to this than I've listed here. However, you can think of this in almost archaeological terms - each layer over time making it easier or faster for someone to build applications using a computer. Spreadsheet programs are a good example of building systems that allow an end user to leverage the power of the computer to handle complex calculations with little need for the user to understand programming at all.
That being said, I agree there are a lot of extraneous languages, frameworks, and development environments out there that makes it more likely that people will create buggy code. The farther away from the CPU - in terms of abstraction - the less you will know about what your application is really doing 'under the hood'. As a result, I do suggest a clear bias towards simplification in the selection of languages used to build the underlying systems for the use of people to solve problems, coupled with perhaps certification programs to make sure what is being built is being built good.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
I've worked with lots of people like that boss. If you try and get more detail, you're chided for not working quickly enough, or for bothering them. My policy is always to give such people what they ask for. If they can't or won't learn, that's not my problem. Their spouse/parents/pet can change them. It's not my job.
If you try and get more detail, you're chided for not working quickly enough, or for bothering them.
Well, you'll never get very far if your boss is entirely unprofessional, to be sure. But "not working quickly enough"? Sounds like there isn't a schedule. "Bothering them?" doesn't take much time to answer a few questions - most people are happy to explain what they want, feels like leadership.
My policy is always to give such people what they ask for.
While passive-aggressive bullshit is a common approach among programmers, it's still a bad approach.
Socialism: a lie told by totalitarians and believed by fools.
Ooh, dragons.
1. Multithreading. In some languages (e.g. Java) multithreading is no worse than any kind of parallel processing. Can you be a buffoon and fail? Yes you can. But you can do that in a single-threaded program too.
In other languages (e.g. C) the chance of errors impacting some completely random data structure are so high that it's frankly important to stay away from anything that would confuse the control flow, such as multithreading.
2. Closures. Okay, you're talking about Javascript here. javascript is a hideous language which should not be used to the maximum extent practical. Why complain about closers when all of javascript is bad mojo?
3. Too big data. Also known as lazy-ass programmers who don't want to be bothered to deal with the possibility that their program may be called upon to process a large data set. Solutions for processing large data sets explicitly on the disk (not with virtual memory) are well understood. You just have to choose to use them.
4. NP-complete. There's no particular dragon there... the elephant in the room is those programmers too ignorant or clueless to bother computing the big-oh running time of their algorithms, so they write software that appears to "lock up" as soon as anyone gives it a useful data set to process.
5. Security. Correct security implements defense in depth. Break one level so what? Even patched slowly, it's patched before enough layers can be broken to grant access.
Programmers make two classes of stupid mistake:
a. They assume they don't need defense in depth because they've written secure software.
b. They carelessly implement functionality that cuts through all layers of security. Like single-sign on.
6. Encryption. The odds of a long-surviving conspiracy to hide mathematical breakthroughs which bypass encryption are essentially zero. You can relax on that score. You can also expect one-time-pad encryption to remain unbreakable regardless of mathematical improvements. Because no analysis of extremely long strings of random bits is meaningful.
You have to be pretty bone-headed to mess up security in this day and age. Yes, many many programmers are bone-headed. But that's not encryption's fault.
7. Identity management. The only thing which makes this hard is its constant misuse. No authentication is perfect, so correct programming makes authenticated actions reversible instead. The more critical the action, the more critical it be reversible.
8. Measuring hardness. Now we're in to mumbo-jumbo territory. A simple big-oh evaluation will tell you whether your algorithm is usable. Trying to figure out whether it will be easier or harder to solve one problem or another, neither of which have a known useful algorithm? Silliness! Problems like that are solved when someone finally has the key insight. Inspiration is not a product of work, it's a product of the creative mind.
9. The authors can't measure. They claimed 7 but listed 8 things.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
They missed the most vexing problem of all. Hiring a skilled and talented old timer programmer to come solve the problems that fresh faced recruit coders created. Then offering the same rate as they paid the fresh faced recruits, not being able to grasp that the ability to solve, often under tightest of all deadlines, messes left by inexperienced programmers. In some cases less! I have personally had the extreme joy to explain to a physicist that the code he wrote, while it would solve his problem, was written in a manner that the solution was of order O n squared. While the problem could be solved in an manner that mathematically provided the same solution but was order O n. The physicist then said he wanted to test both solutions. His was actually faster on a data set of 100 items. (Lots of fixed constant cost was involved, my solution had more precalculation setup, so for small sets of data, my overhead was more) He proclaimed himself the winner deriding my science. I asked (already knowing) what the normal sample size was they analyzed? What, 100,000 samples? Sure let's use one of those... 20 minutes later mine was finished, I cleverly asked to run first since I lost the prior test. He ran his. It took a while. The next morning his finished. The results were the same. Save the physicist was a mixture of miffed and conciliatory. Very brilliant physicist. Not so great at mathematics. I've even encountered programs implemented in a manner to be non-deterministic when a deterministic solution existed. Vexing is working with some programmer that thinks they know everything. Which really annoys the ones that do.
When will Slashdot fix all of the problems with its by now obscene code. Or any? When is the last time Slashdot had a meaningful update instead of delivering unasked for "features"?
Multi-threading isn't that hard if you have some experience and a good library.
When I see comments like that, I translate that to: Has bug-ridden threaded code that causes intermittent problems that get ignored because they are intermittent and hard to track down. Probably not even aware that they are caused by multithreading bugs.
All of the other problems can be solved with redundancy, fault isolation, defense in depth, argument and result verification, approximate solutions, backups and so on. Threading problems even in most naive code are rare in practice. You are probably running something in a thread because it's quite slow, and the probability it will finish and try to update a shared data structure just when you are using it is low. The trick is to avoid writing corrupted data to database if it does happen.
It's not truncated, he used strcpy() and it's overflowed into the next memory block, along with the nop sled and 0day exploit.
your joke was so funny, i decided to reply to it instead of yawning myself to sleep by the time i'd finish reading it.
Any guest worker system is indistinguishable from indentured servitude.
One of the biggest problems is reading stories like this on Slashdot, about how everyone solves NP by approximating it over the lunch, pulls some deep-learning with N types of layers and nets out of their bottom just for fun, knows 15 different programming languages perfectly, changes to the latest shiny language every year just because, and switches their frameworks and programming paradigms 5 times a year, while effortlessly solving any math problem they last heard about 15 years ago, in their 5 minute agile iteration, in perfect multi-threaded and distributed synchronization, etc.. Me, I just try to do something useful with whatever I know, while learning some selected new stuffs (with proven benefits) when I have time. Often it is not even (directly) programming related. Boohoo-hoo, so the problem is me, of course! :)
So you are comfortable writing code when you 1: don't know the customer and 2: don't know what they want ... after all this is just a management problem.
For a spec to be that good it's got to be written to the same precision as a computer program.
So just write the fucking code.
It's the other way round: closures shot dynamic binding dead. In general, lexical scoping is better for programming languages than dynamic scoping, in both theory and practice.
There's lots of information on the Internet about this but here's a quick link: https://courses.cs.washington....
Javascript has both lexical and dynamic scoping: 'this' is dynamically scoped and everything else is lexical. While 'this' is used extensively in Javascript, it's really a mistake. You can do all the useful 'this'-style things with closures alone, and it's easier to reason about.
Agile is meant to help you learn about the problem domain. If you already know everything about the problem, there's no need for Agile. If somebody else already knows everything about the problem and you can hire him/her, the do it - no need for Agile. If nobody knows everything about the problem because it's a new problem that no one else has worked on yet or a new approach to a known problem, then you definitely need Agile or something similar to help you produce something that works at the same time that you are learning about the problem.
I would put it like this: if you have a good PM, he or she will choose the right tools for the project (Scrum, XP, Kanban, pair programming, waterfall, whatever) and the right people (developers, QA, BA, etc), and will customize the tools as needed. If you have a bad PM, or the budget doesn't allow for putting together a good team, then it doesn't matter which tools are used.
I currently work in a project where:
- there are no schedules or estimates,
- everyone seems to believe that tickets with a three-word title and an empty description fit the definition of "spec", and
- answering questions with just "yes" or "no" sometimes takes weeks, even if the ticket is urgent and not answering the question blocks further work on the ticket, and
- the codebase shows attempts at following every programming technique, concept, trend or fad from the last 10 years.
Fortunately, it's not as bad as it sounds because all the current BAs, developers and DBAs are making a great effort to improve things, but it's still bad.
Well said!
he missed out on the programmer as the biggest problem:
a) underestimates the work.
b) overestimates personal abilities.
c) lacks the exerience to prevent a+b.
Nope. I've worked with a lot of developers and when they make their own decisions they get it right. Mix project management into it and you have a single point of failure that usually don't get neither the customer nor the technology.
Oops. Undoing troll mod. Meant insightful
OO is closures on steroids; why continue to use them?
What is a closure? It is a way of preserving data which can be accessed later via a single function. What is an object? It is a way of preserving data which can be accessed later via many methods. OO is augmented closures.
Don't stop where the ink does.
This is often compounded by:
1. Customer changes as the project goes along and the importance gets kicked up the chain in customer's hierarchy, or, the VP loses interest and kicks the project down the chain wherein the project is suddenly confronted with reality.
2. Once a demo/prototype is running, the customer says, "That's great, but it has to do x as well."
Both problems are we called the Moving Target problem which can be solved by spending a lot of time up front specifying the scope and specifics. Too often this portion is done badly by salespeople trying to close the deal and move on to their next victim. Deadlines are established with too vague an understanding of what the target is, and project managers are left with an impossible task which they solve by compromising in the aforementioned areas--especially in hiring sub-par coders just to meet a deadline.
Agreed, up to a point.
The problem comes in when the customer wants to do an update, extension, or major fix. Someone else comes in and your code is a mess because you were focused on a happy customer and delivering something that worked well enough at the time for less cost.
In the long run, your lack of method cost the customer more (or they had to go without the update, extension, major fix) because it takes too much time to figure out the code, or it is just better to redo it all from scratch.
For a spec to be that good it's got to be written to the same precision as a computer program.
So just write the fucking code.
The spec is as much for the customer as for the programmer. It defines goals, not how to reach those goals. But, yes, it can take as much work as actually writing the code. Your solution is actually not a bad one if the problem is small, but it doesn't scale well to larger projections.
Well, I'd be the last person to advocate jettisoning methodologies, any more than I'd advocate jettisoning architecture, although I've seen both abused by people who make fetishes of them.
My point is that software development is multidisciplinary. You can't rely on one kind of discipline to ensure success.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
1 who's my customer 2 What does he or she actually want.
Sadly this is a problem that is NP, therefore we must solve P vs NP to satisfy it.
We'll make great pets
Arbitrary truncation of data...
640k oughta be enough for anyone
We'll make great pets
The only reason multi-threading is considered a hard problem is because people are grossly under-trained and overly optimistic. If you're just like "I want this to run asynchronously so it's not blocked and get more performance so I'll throw it in the thread pool" you are going to end up with nightmare code. Proper multi-threading that is high performance requires good orchestration of tasks much like an OS task scheduler. You also have to think in a parallel computing mindset. For example let's say I have a composite operation that consists of Task A, B and C but I don't care what order they finish. They way to do this is to have a structure that houses these tasks and when the last one completes there is a callback function that signals something else to continue onward processing. It's actually not that difficult but most people can't be bothered to learn how to do things like this properly.
We'll make great pets
It's a well-known sales tactic to put the preferred option in the middle of a higher and lower option. They can still feel like they're saving money, but are paying more than the bare minimum.
and an associated endless stream of unmanaged change requests. There's a real dragon for you.
He's not saying that, he's just saying it's not a pure "programming problem" if you really need to pull in non-programmers (in this case, the customer) to address it.
I remember my computer teachers talking about this exact same problem - way back in 1986.. Nothing has changed.
Below the speed of light Special Relativity is one of the most accurate theories in physics - above the speed of light..
Healthcare based on insurance is an inefficient system to begin with. You have the basic contradiction of poacher/gamekeeper (cover is only profitable on healthy people) and you need a massive bureaucracy to contain the thing. That's why socialist healthcare systems tend to cost about half of what insurance based ones cost..
Below the speed of light Special Relativity is one of the most accurate theories in physics - above the speed of light..
Your definition of object-oriented programming is in direct conflict with the definition used by the guy who coined the term in the first place, Dr. Alan Kay. You've confused the an object vs object-oriented programming. Most every program has functions, very few properly use Functional Programming. Similarly, according to Kay (and any random textbook you choose to consult), just because call something an object doesn't make it OOP, any more than calling your hour-long meeting a "scrum" makes your process Agile.
My view is that programming cannot be considered a career. My analogy is the clothing sweatshop. You have the sewing machine operators (programmers) trying to sew garments (the sub-problem) and the two parts do not fit together.
Who wants to be a life time sewing machine operator anywaY?
Leslie Satenstein Montreal Quebec Canada
Well, they can program, sort of, for limited data sets and valid input and careful usage. Then they are totally shocked when programming for realtime continuous data and corrupted input and full protocol validation isn't as simple. And once in management can't understand why their schedules never work.
Write the code, but for the love, make it readable. Make it so readable to the point that you can show an implemented business rule to the guy who will be using it, and he should be able to make out what's going on even with no programming experience. (Not lower level database access, UI code, etc.)
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
But to answer your curiosity: why the fuck (sorry for the language but it is appropriated here) should I waste my time with mental masturbation and allocate and deallocate my objects manually?
Because the garbage collector is bad, and you can't specify when it should run so Java programs get all bloaty.
Rational thought is the only true freedom
Yep they also missed refactoring Spaghetti Code
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Kay created the title Object Oriented Programming as a label for his system of ideas. He's the authority on what Object Oriented Programming means - even if I find some applications of OOP annoying at times. Even if I thought all of his ideas were stupid, still his ideas would be called Object Oriented Programming.
if you want accuracy for things like currency you are better to use something like cents instead of dollars, than a double 0.01 is actually
0.010000000000000000208
I am aware of the problem you describe if you try to store euros/dollars in a double. But if you store cents in a uint32_t, you can't hold values greater than about 42 million euros/dollars.
Of course if you stick to integers doubles will be fine as long as you do not exceed a 53 bits.
Exactly. I don't see how storing integers in double was so bad, especially in pre-C99 code. JavaScript code has to do this, as does PHP code running on a 32-bit architecture. Storing integer cents in a double is fine out to 90 trillion dollars, which still exceeds the U.S. national debt. (For now.)
If I write a DeepClone() method on my own class then how am I repeating myself?
Your source code contains the list of all fields in four places: first, the definition of the class's fields; second, the definition of DeepClone(); third, the definition of serialize; and fourth, the definition of deserialize. Do you have a means of keeping these four places in sync automatically, such as by reading the definition of the class's fields and generating the other three from that? Or do you spend a lot of time manually fixing defects that your 1.5 round trips test finds?
The Agile method is God's gift to Time and Materials contracts.
Sorry, you are wrong.
The Java garbage collectors are very good and you can chose between about 10, and parameterize them as you like.
And on top of that: of course you can specify when they run. Facepalm.
System.gc();
But why would you?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Do you have a means of keeping these four places in sync automatically, such as by reading the definition of the class's fields and generating the other three from that?
I would love to have a generic DeepClone method that uses reflection to make a "perfect" copy of the object tree. Unfortunately, that is not fast enough for my needs.
Then perhaps I wasn't clear enough. You could write a program that instantiates each object, uses reflection to find what to clone, and outputs a corresponding DeepClone method in C#. Then the slow reflection stuff happens on the developer's PC, and its output gets compiled into your executable.
That you think that the System.gc() call invokes the garbage collector is the kind of thing I hate about the garbage collector.
The System.gc() call does not call the garbage collector, it notifies the collector that there is garbage to be collected and the JVM still makes the scheduling decision. In practice it may lead to immediate garbage collection, but that is not necessarily the case.
Secondly, you CAN specify your own garbage collector or specify one-of-the-many that exist, but an explicit call to System.gc() usually forces the collector to check if all the objects still allocated are reachable so the process can be quite inefficient. If you're using Java, calls to System.gc() should be very rare.
Lastly (to clarify something i said above, and this is not the garbage collector's issue) the JVM heap size rises independently of the Java allocations so garbage collecting doesn't return heap to the system.
Rational thought is the only true freedom
The System.gc() call does not call the garbage collector, it notifies the collector that there is garbage to be collected and the JVM still makes the scheduling decision.
a) depends on the VM
b) of course it does, otherwise it would not make any sense at all.
the JVM heap size rises independently of the Java allocations so garbage collecting doesn't return heap to the system.
Of course it returns heap space. What other kind of space should it return? It does not shrink the size of the heap, though if you mean that. And why should that make sense anyway?
usually forces the collector to check if all the objects still allocated are reachable so the process can be quite inefficient. ;D but let the memory management system decide. OTOH, if gc() really gets executed, it just behaves like "the real thing". In other words, if you have a generational collector, the standard, it checks only the youngest generations, and it only runs till it decides there is enough free memory ... actually it usually does not run at all. ... or at least bad style.
That is why you don't call it
It is an anti pattern to call System.gc()
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Eatted, not et.
>Unicorns don't exist in the real world...
Yes they do, they are also known as rhinoceros, are ugly as homemade sin, and mean.
+1. Units are metadata if they're not part of the object model/structure. The variable name should tell me what a thing is, not how it's configured. There's absolutely nothing about a variable name that guarantees any compile or runtime safeties to be sure that what you think you're dealing with is what you're dealing with.
I typically make my units (or "non-object-model" metadata when appropriate) a member of the class/struct/whatevs as an enum. As a bonus, in most modern languages your enum is a class that can be extended to have methods/functions so you can add support for type/unit conversion into the enum itself. The icing on the cake is that you can write fast, scalable, easily readable code by checking the units in a switch statement where you might otherwise be inclined to have a bunch of "if" statements that become messy as you must support additional units.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.