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
None of these are real problems if you use the right tools. One-off errors and having to write too much glue code are more of a problem.
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!
the idea that functions must be bounded to data is ridiculous. data and operations are duals and each can be thought of acting on the other. polymorphism leads to code bloat and decreases readability (you always have to be mindful which class in the inheritance chain a particular method came from). Also, compile-time is way too early to make a decision on which particular way a particular piece of data will be treated. Especially if these pieces of data come in homogeneous containers. The binding of behavior to data should have been done through better syntax which would allow it to happen pretty far into the run time.
Any guest worker system is indistinguishable from indentured servitude.
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'
While I agree that they can be difficult, they exist for a reason, and frankly, with some proper study of functional and parallel programming, they can be used correctly. Closures have been a part of programming since LISP and frankly, higher order functions and functional programming can solve a lot of problems quite nicely. Certainly, mutability makes that a bit more difficult, but it can be managed. Finally, figuring out what variables are captured in a closure is quite doable by static analysis, which would be a nice addition to some programming environments.
Threads are more difficult for sure, but there are frameworks that can provide some useful higher level abstractions to make there use a bit easier. Lower level usage can be quite difficult, but a bit of actual thought and design goes along way. Also, there are some really powerful tools for multithreaded debugging, they just aren't freely available.
Mainly, I've found that people that can't manage these abstractions just don't have enough background in operating systems (which also discusses basics of concurrency) and functional programming, topics that used to be required in CS education. They can be learned and it can increase your overall code quality and reduce some frustrations.
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.
I've run into WAY too many programmers whose only solution to ANY problem is to write more code.
Not fixing the broken crap they've already written, not buy faster hardware because the current system is too slow.
It's always, "I MUST write MORE CODE to solve this problem!"
Multithreading isn't easy, but it's not exactly Nobel Prize material. It's probably like contract law for lawyers - it takes a while to develop competence.
Throwing that in with NP-complete and security (and the latter two with each other) is nonsense. Security is obviously going to always remain unsolved as long as technology keeps advancing, because the attackers are wily humans who use their creativity to probe for new weaknesses. And NP-complete basically means that no scalable solution exists, so you have to simplify or work around whatever it is you were originally trying to do, or settle for small problem sizes.
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.
What do women want?
But that's the domain of pop music, TV sitcoms and movie rom-coms, and stand up comedy.
last minute one liner that won't harm anything, wink wink.
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....
And does it support Azure?
Re: Serious he missed the 2 biggest problems I've h
Arbitrary truncation of data...
The Boehm garbage collector can set mark hooks. Now do the garbage collection functionality in some base class. Some derived class marks its own members.
The base class sets up a hook for marking. The asynchronous nature of garbage collection means that this marks the time from which on the hook may be called. But base classes are constructed before data members are constructed. If you have something like
std:vector blubber;
virtual void derived_mark const () { for (auto i = blubber.begin (); i != blubber.end (); i++) mark_fun (*i); }
in a class derived from a garbage collector managing class, then by the time derived_mark may start to get run (via the garbage collection managing base class), blubber may still be a bunch of uninitialized memory.
Which is really awkward.
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.
-nt
Customers are happy as long as they don't find out that Agile costs 4x more and you're spending 90% of your time code refactoring. Or worse, not refactor and watch the system implode.
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.
See subject: One I've encountered in my professional days (long ago over, my money works for me, not the other way around) - the "picking problem" - look it up boys, I won't do YOUR HOMEWORK for you...
* They overlooked THAT one... especially in industrial application (keyword application, PRACTICAL real-world application, where the "rubber meets the road"...)
APK
P.S.=> "Onwards & UPWARDS"... as I am a "show me" person - theory be damned, follow the data etc. - et al... apk
Still not "programming problems", they are project management problems. You are going to be hit by them as a programmer but that is not due to your programming but because someone at management screwed up.
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.
1. Idiots
2. They don't know- And the worst possible way to find out what they need is to ask them.
Welcome to programming.
I found myself re-inventing some kind of message passing when I worked with threads. Then I read about Erlang. I've never coded in Erlang, but it's my understanding that's the model there and it's very robust and not so easy to shoot yourself in your foot. That validated my approach. I'm sure it's not a silver bullet; but whenever I've had to deal with threads I've thought in terms of MP, and I didn't end up with a shitfest of memory leaks and race conditions so I must have done something right.
is proof that they hate us. The Bush Crime Family made him their boy because he is a violent thug that wants to see every person that isn't a white male die. He was wrong when he said there are known unknowns and unknown unknowns. That doesn't make any sense. Only stupid people believe that garbage. Bush Jr is such an idiot.
1) Real-time Inbox (different types of data need to be displayed differently...also depends upon the user's role...custom "quick-access" functionality/workflow/routing/approvals based upon data type and role...testing)
2) Scheduling (permutations of cases and exception cases [e.g. blue moon on a Thursday except in months that start with a 'J' and where the day is prime]...order of operations...testing)
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.
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
Half of you seem to be talking slang rubbish that you have invented yourselfs,that seems to have variable meanings to different groups. ..
I consider all of you as a great waste of time,resources,you appear to have created an entire system(s) of rubbish.
Why is there not just one language and one code system that anyone with the right knowledge can use properly to give guaranteed results if you do a+b+c =d,every single time ?
Why are there more and more different systems and languages every year which less and less of you fully understand.
Why can there not be one "universal" system of code that can be used to do anything ?
As you have guessed,I'm not software trained,have little understanding of higher level maths etc.
But I have lived in the " real world" for 57 years and I can only say that thankfully the rest of the world seems to work on a totally different idea to the ones you have invented.
Coding is just engineering with binary language,lucky for you lot that the rest of us work on the basis that a+b+c=d,and if it doesn't,things fail spectacularly,lucky that you lot are not in charge of building things that just have to work,from the simplest bedside cabinet to the power systems that you lot all rely on to power the chips that you all rely on to run the dogs dinner of crud that you have created over the generations of apparently bodging stuff just enough that it kind of works the majority of the time as you reckon it should..
Seems like the biggest waste of human brain power yet
I know many of you will jump down my throat about this and that,but try looking at your world from the view point of a total outsider,you would not be impressed with what you saw..
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.
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.
Employee theft. #2, Employees not showing up for work. #3 Employees that can't do anything.
See a pattern?
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.
Event-driven interruption of routines,
Multithreading
Buffers
syntax conflicts with pointers to pointers
Managers who are not programmers
Things like Agile, which ignore pre-design
Corporations that thnk it only takes an hour to put in a change
Each customer wanting their own lttle change ( scope creep anyone?)
This why programming is not engineering - Engineers design before they build. Programmers and some managers/bosses tend to add the chimney after buildng the house....
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.
> 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.
And divorce lawyers.
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.
The parent comment is underrated. -PCP
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.
1 have product
2 this is what you want
create the trend
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
If Java didn't have threads, it would just be strongly typed javascript.
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.
How come computers still respond in perceptible time? How come things aren't instan-fucking-taneous? I mean shit like opening a window on a desktop, why can I still see the icons being populated?
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.
Java was a good tool in its day before multi threading was a main stream concern. Java has evolved away from those primitives in libraries to maintain backwards compatibility.
You can see the evolution of this thought at the language level if you look at Go / Erlang
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.
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.
You're part of the problem for referring to ports as "legacy". Just because tge hipster twats who work at Crapple think that anything other than their Bluetooth USB-C Chunderbolt gash is somehow outdated doesn't give them the right to deem it "legacy". Who defines "legacy"? Where does it end? A few years ago I was hearing about "legacy-free" motherboards (=no PS/2 sockets)...
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.
You mean programming?
Yeah, it's a minefield. Obvi.
RIP Slashdot...
I once inherited one huge access/vb application that was this....thousands and thousands of lines in one procedure.....ye ha! The history was it was the same contractor that would come in every 3 months to fix something or add more over the course of 10 years....so it was just 10 years of bandaids pretty much. All procedural, just figuring anything out could take days....
In his defense the owner/ceo was an idiot and pretty hard to work with, my best guess is he just didn't care and figured it was easy money....made my life interesting thats for damn sure.
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.
They know what women don't want.
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.
If you have good developers, and a good project manager, then it doesn't matter whether you use agile or waterfall, you succeed either way.
If you have bad developers, or a bad project manager, then it doesn't matter whether you use agile or waterfall, you fail either way.
Go hire a shepherd!
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.
He didn't want to delve too deeply when the first sentence was "Find gay porn on the internet."
Ever check for free space on disk before writing? Of course not, you just assume you can write that file until BOOM! no more space left
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.
>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..."
Erlang
http://www.erlang.org/
Learn it
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.
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.
My boss is the customer. If the customer requests something the USER didn't want, that's not on me or my boss, it's on their boss for not getting confirmation from the users before he signed off and told my boss to have make it.
You don't get to tell the lumber supply guy to cut the boards in half when you meant thirds. Well, you do, but he's still charging you for both too. Just because you may not understand the difference between bits and boards doesn't mean you get your money back.
Now, if you hire ME to PM, I'll annoy both bosses and teams with follow up questions, fragile, unscalable mock ups and proof of concept every step of the way. If they don't give up, they'll find the last round of what they thought was spec extraction actually leaves them with a working product. But half of clients give up when they realize they need to fix their process, not automate it. Which is why I bill each step as a discrete, non refundable sub project.
Quit in step 7? Fine, since I'm already paid through step six as per our agreements.
How does that help?
If you get the same completely useless piece of code from 2 different developers, your spec is actually WORSE than a spec where you get completely different results.
You describe a PRECISE spec, which is worse than useless without it also being a CORRECT spec.
And the latter is the far bigger problem and far more important thing than the former, even if you'd really like both
After np complete, second largest obstacle in programming is appropriate variable naming.
Most likely it is one of inner circles of hell
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.
> You have to be a bit careful about locking around shared objects, but usually the answer is avoiding shared objects.
But exactly this is the raison d'Ãtre of threads. If you don't need shared objects you don't need threads -- concurrent processes are the way to go (if you're doing threads with message passing and no shared state, you are basically doing concurrent processes, the "threads" part is just a technical detail).
Shared objects (and thus threads) are arguably unavoidable when your objects are so heavy that you've got to share them. But then you buy into a sizeable amount of pain.
I stay by my claim: threads onyl if you must.
You honestly expect that the conversation would have gone differently if he had asked? Oh you're right it would have been followed with a "just throw something together and we'll tweak it afterwards".
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 spend a LOT of time in Java messing around with the garbage collection as well.
Hey, why do I have a memory leak? Oh, it seems I am keeping a pointer around here, and the compiler can't see it will never be used again.
Hey, why does my program crash? Oh, it uses more memory close to the Java heap limit and the VM just kills itself when doing GC becomes too difficult.
Hey, why is my program using a lot of memory kept alive by weird references? Oh, it's classes with finalizers, and the GC never got around to calling all those finalizers.
Hey, why am I running out of disk space? Oh, the above problem means that all those files I just deleted are actually still there because the OS thinks they are still used.
Hey, why is my program so slow? Oh, I have a new in the inner loop and GC can't handle it. Well, looks like I'll have to write my own memory allocator! As bonus, I get all the disadvantages of new/delete back!
Well, as a first hack I can also throw in random calls to the garbage collector. Of course you're strongly advised to not do that. Well, why don't you assholes write a working garbage collectors first (since you decided to design a language needing it) before advising other people?
C/C++ at least has great tools like valgrind, the Java tools are utter crap pretty much across the board (CPU profiling tools: slow you program down to a crawl, but can't even give you line numbers. Heap profiling tools: usually can't even tell you which code allocated the object. Compiler: doesn't even do trivial optimizations, so the binaries are bloated like hell, build systems: bug infested crap, with every new version of gradle there is a some bug that breaks things etc., etc.).
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.
Goto is used in C (especially kernel) to handle the error cases in a consistent way.
It tends to be a lot better than the alternatives (it also cannot lead to "spaghetti" code since it's always a jump forward, and usually to a single target).
Java and C++ might rather go with exceptions, but the basic issues and resulting code flow are the same, and especially for C++ it actually has a couple of additional issues like performance and the risk of leaking memory unless you designed anything that might end up in a temporary to clean themselves up properly automatically when going out of scope.
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.
Using a 4GL with unnormalized data
In a deplorable insurance company that actually exists, maintaining assembler code on ibm 360 architecture, where the base registers are maxed out, and where splitting up the modules is not an option, and where re-writing the code in a higher level language is not an option.
Taking a 48 hour job and whittling it down to 12 hours on the same computer.
Maintaining machine code without a compiler on a legacy rocket system
In a shop with bad management, putting new code into production without system test.
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.
Well not everyone can quit or get fired which is the only other option. That's what happens if you don't give them something. If you like to keep your job giving them what you think they want is the only way.
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
Multithreading (I agree with that)
Security (If he means bugs causing holes, yes)
Focusing on the understanding the problem and the customer is (see usability)
Schedule estimating and execution (see making a baby with 9 folks in 1 month)
Excessive cleverness (see all the features in C++)
Fear of learning curve causing thing to be redone instead of reused.
Not understanding what a computer is and how it works (Especially pointers, malloc, free, but other things as well)
Secondary items:
Execution time
Architectural purity
Language choice
Agile versus not
Offices versus team rooms
Most everything else on the article's list
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.
AFAICT, legacy is defined as "old shit we're not allowed to get rid of".
and an associated endless stream of unmanaged change requests. There's a real dragon for you.
I could not agree more!
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.
That list is redundant
Anyone mention that whatever nitwit wrote this article doesn't understand what virtual memory is at all? When he says virtual memory, what he appears to mean is physical memory allocated on the disk rather than in RAM, that is, swap space.
Most people can glom together a bunch of code and get it to work. The hard part is making the logic easy to follow. Clarity of code is the key.
* If there's a bug, and the code is clear, the bug will be easier to find and fix.
* If it's on the wrong platform, and the code is clear, it will be easier to port.
* If it's too slow, and the code is clear, it will be easier to streamline.
* If it needs a new feature, and the code is clear, it will be easy to add.
etc.
Remember, the audience of your code isn't the compiler or interpreter. It's the intern who will be reading it two years from now. Don't be clever. Be clear instead.
You were taught wrong.
Or you mistook a fairy tale for a lesson.
Unicorns don't exist in the real world...
I resemble that remark pardner...
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
I hear that some websites support obscure foreign characters, like the symbol for UK currency: £
Maybe even really obscure stuff, like the Euro symbol: â
At this rate, we'll have a man on Mars before Slashdot supports Unicode.
Bravo! YES.... Listen to the people who pay the bills. The money trail inevitably leads to one or more key business areas.
Isn't RUST supposed to make threads 'safe'? Statements from RUST team say that newbies can write thread safe programs in RUST.
Now that the tools are available why not use them?
How many 'buffer overflow' exploits would not happen if code (even kernel code) used 'safe' string handling routines, (or better safe string objects?)
No point in blaming your tools if you keep using a hammer to break the board when you could be using a saw to cut it.
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.
Put everything in one huge massive universal class of doom. Kiss refactoring goodbye!
I've found this works great, as long as I use goto statements to move around within the class.
Shitted, not shat.
Sitted, not sat.
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.
Also, quit hiring MBA PMs who know nothing about user experience or software development.
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.
See subject: Yes, & in a (now even more) 142++:1 ratio against you https://slashdot.org/comments....
* NOW THAT IS FUNNY!
APK
P.S.=> Change your diet K.S Kyosucky - EATING YOUR WORDS != GOOD NUTRITION, lol... apk
+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.