In a series of experiments (pdf), researchers set out to discover the relationship between difficulty or "disfluency" and cognition. They presented the same test to two groups, one in an easy to read (intuitive) format and the other in a difficult (disfluent) format. And in all the experiments they carried out, the disfluency group scored substantially higher. The theory behind this is that people will default to relying on the automatic, effortless, and primitive system for reasoning. But if things are counter-intuitive or harder to understand we switch to the deeper, deliberate and analytical mode of thinking.
I've been thinking about how this translates to programming. Programming is an intellectually challenging task, but luckily we invent tools to make it manageable. I find that up to a certain point, the intuitive and easy properties of a given language, framework, or library might start to have negative effects. From personal experience and from mentoring beginners I noticed that when using tools that allow us to reason within our intuition, anytime we're faced with some difficulty we feel that we've done something wrong. And although we might have the necessary skills to overcome the difficulty, we often start questioning and revising our work. Asking questions about best practices relative to the framework instead of programming our way out. The quintessential example of this is the Stack overflow questions for "how do I use jQuery to do X?" or the answers "use jQuery [plugin] to do X" where X could be anything from basic arithmetic to websockets.
(Score: 2, Insightful) by Anonymous Coward on Tuesday January 05 2016, @10:18AM
the concept of "space" in mathematics has been a huge help in proving various results particularly because we can use the monkey brain to think about very abstract stuff, we just need to take care of having a correct relationship between "abstract properties X, Y, Z" and "distance, angle, color" or whatever.
the entire point of performing many exercises of something is so that the corresponding processing becomes "second nature", i.e. it becomes intuitive.
if you make it harder to work with something, just so that you're sure you're giving it your whole attention, you will just get very tired very quickly, and either give up or get used to the new workflow, therefore using intuition again.
(Score: 0) by Anonymous Coward on Tuesday January 05 2016, @12:28PM
>if you make it harder to work with something, just so that you're sure you're giving it your whole attention, you will just get very tired very quickly, and either give >up or get used to the new workflow, therefore using intuition again.
Probably true for day to day tools, but maybe untrue for educational stuff?
(Score: 3, Interesting) by The Mighty Buzzard on Tuesday January 05 2016, @11:43AM
Thankfully Rehash creates no such problem. The codebase itself is large and disparate enough that you don't even try keeping the minutiae memorized. You remember the overall structure and the coding conventions and have to relearn the specifics every time you step away from an area of it for more than a week or two.
And then there's good ole perl. Nobody should ever get too comfortable with perl. You'll always find some new wackiness someone's done in it that will act as a speed bump.
My rights don't end where your fear begins.
(Score: 3, Insightful) by FatPhil on Tuesday January 05 2016, @11:50AM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by JoeMerchant on Tuesday January 05 2016, @02:00PM
The whole "easier is more error prone" thing falls apart when you reach the stage of automated code generation. If a task is repetitive enough to be automated, then automating it takes you from random error rates to constant and controlled/repeatable error rates - and if you address the errors in the automation you can get them down reasonably close to zero.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by FatPhil on Tuesday January 05 2016, @02:29PM
I shouldn't complain, removing design patterns put in by so-called programmers who didn't know the first thing about how to design anything was the highest paid gig I've ever taken, and that was a decade ago. (And I think I actually found some O(n^3) code there too (same range of n).) My performance review was amusing - apparently my productivity at the end of the year was *minus* five thousand lines of code. Having said that, I'd also got rid of 7 dead-wood programmers too, so I was great for the bottom line.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by JoeMerchant on Tuesday January 05 2016, @09:30PM
I had a PhD who wrote code to compute a histogram that included an un-necessary layer of looping in it, slowing down computation by a factor of 100 (to something just barely unacceptable). I explained it to him, patiently, but he never did understand how it could be done without the extra loop, even when the two routines were given to him side by side producing identical results.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by FatPhil on Wednesday January 06 2016, @02:50PM
void thingy::set_channel(int channel)
{
int i;
int bit = 1;
for (i = 0; i <= channel; i++)
bit = bit << 1;
this->channel = this->channel | bit;
}
We used to say that really bad code was "Thierry bad" after Thierry, the guy who wrote the above, had left the project.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by JoeMerchant on Wednesday January 06 2016, @05:14PM
That is certainly one way to do it... I try not to care about stuff like this if it's not really impacting performance in a meaningful way - but it is hard.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by FatPhil on Wednesday January 06 2016, @08:57PM
bool thingy::get_channel(int channel)
{
return (this->channel >> channel) ? true : false;
}
(try setting and getting channel 0)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by JoeMerchant on Wednesday January 06 2016, @09:49PM
Well, a testable failure is not as evil as a non-testable failure. Definitely don't let Thierry near multi-threaded code.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 3, Disagree) by Thexalon on Tuesday January 05 2016, @04:44PM
Automated code generation should not be either necessary or useful. Thankfully, a lot of people have put in the time to make them go the way of the buggy whip, so long as you're making use of the right tools and language features.
Some of the more common code generation scenarios that should go away:
1. Get/set methods for all your properties on an object: The reason that this used to be common practice was that those methods represented the possibility that how those properties were defined might be modified sometime in the future. But now, most OO languages have added the concept of property methods, which allows you to define methods that look to the outside like properties (i.e. "myobj.foo" actually calls myobj.getFoo() or myobj.setFoo() as appropriate), so you can just make the property public and use it without fear of forcing yourself into a corner.
2. Similar-but-different methods for a bunch of related classes: The "similar" part means that there's almost definitely some shared functionality that should turn into either a base class or a utility class. If the "different" part is names changing, then what you need to do is make use of reflection and/or configuration so that the similar parts are now identical. Again, reflection didn't always exist back when this sort of problem was solved with code generation, but now it is widely available and should be used where appropriate.
3. Complex procedures to turn one kind of common configuration file into another kind of configuration file that used to be the only way to configure the thing in question: The tool should be modified to understand the initial configuration file as well as the newly-generated configuration file. For example, sendmail should be smart enough to understand sendmail.mc as easily as sendmail.cf (alternate solution: Don't use sendmail, because postfix and exim are at least as good).
I see automatic code generation as a kludge that masks a bigger design problem - possibly a design problem with the tools being used, but often with what the programmer is doing.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by JoeMerchant on Tuesday January 05 2016, @09:28PM
High level languages _are_ automatic code generation.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 3, Insightful) by meisterister on Wednesday January 06 2016, @12:43AM
+1 to this. Although modern compilers are very complex, massive beasts, they're all ultimately designed to write assembly and/or machine language code.
(May or may not have been) Posted from my K6-2, Athlon XP, or Pentium I/II/III.
(Score: 2) by Marand on Tuesday January 05 2016, @11:26PM
Automated code generation should not be either necessary or useful. Thankfully, a lot of people have put in the time to make them go the way of the buggy whip, so long as you're making use of the right tools and language features.
...
I see automatic code generation as a kludge that masks a bigger design problem - possibly a design problem with the tools being used, but often with what the programmer is doing.
Maybe I'm reading too much into this and it's not what you mean, but the way I read your comment, you've generalised it in such a way that you're also arguing that macros (such as in the various lisps) are unnecessary and bad. It's likely you didn't intend that, considering your examples seem to all be OOP-focused and you're probably axe-grinding about a certain, specific thing but unintentionally including everything else in the process.
Still, macros are a form of automated code generation, and a quite useful one at that. They let you introduce new language constructs efficiently because, when you call a macro, it gets converted at compile time into a different structure that is usually less readable but more efficient (performance). For example, much of Clojure is implemented within itself via macros, creating syntax for readable structures like cond or the threading macros (-> and ->>) that, when created manually, break down into huge piles of nested if statements or otherwise limit readability. They're essentially just syntactic sugar, but I'd much rather use cond's text/expression pairs than a pile of nested if statements any day. Likewise for the threading macros, which turn a nested expression like (take 10 (shuffle (range 0 100))) into something that reads left-to-right, such as (->> (range 0 100) (shuffle) (take 10)). It doesn't seem like a big deal in a contrived, simple example like that, but being able to break down long chains of calls into something that reads left-to-right can be a godsend for readability.
Sure, you can usually (but not always) make functions that do the same things, but at the cost of functionality, readability, or performance. I ran into a situation dealing with Lua, which doesn't have macro support*, where I wanted to clean up some gnarly if/elseif chains to make them more understandable. Something like cond would have been perfect, because the lack of macros meant implementing the same sort of thing either required using load_string (eval), which was readable but ungodly slow, or as a higher-order function that required wrapping expressions into anonymous functions to defer evaluation. The latter worked well enough, but performance was still slower than the if/else chains that a macro could have generated, and the function wrapping hurt readability some (but still better than the original code)
Actually, thinking about it, even outside of lisp-like languages, automatic code generation is an important part of implementing syntactic sugar and new features. It's usually implemented at a deeper level than the end user of a language can appreciate, since most languages lack good (or any) macro features, but it's still there. Continuing with Lua, its OOP is syntactic sugar that generates the clunky table.function(self,args) code underneath the abstraction. Defining function Obj:method() code_here is really generating Obj["method"] = function() code_here for you.
Likewise for other languages; new Java features often just generate boilerplate code for you, doing the same old things under the hood, such as with inner (and anonymous) classes. Instead of changing the JVM, the Java language was modified to silently create top-level classes with special names in the form of Outer$Inner (and for anonymous inner classes, the Inner portion is generated gibberish to avoid clashes). You'd never know it during day to day Java use, because it automatically converts inner class creation and access into the boilerplate code necessary to use them, at least not unless you start using another JVM language, like Clojure, which has no concept of inner classes and accesses them by their real, top-level Outer$Inner class names.
So, all said, I have to disagree; I started this comment intending to focus on macros specifically, but really, automatic code generation is an important part of programming. Hell, if anything, I'd say that automatic code generation is more important than ever because of Javascript's prevalence. Languages that "compile to" Javascript are built entirely on the idea, and the alternative would be working directly with JS (ick). There are certainly cases where this kind of thing is used to solve problems that could be handled well in another way, but that doesn't make the entire concept bad.
* There are special versions of lua that do allow macros, I know. Doesn't help with lua embedded into an application
(Score: 0) by Anonymous Coward on Tuesday January 05 2016, @10:19PM
The two main problems with Design Patterns (DP) is that, first, the rules for when to use what were not clear enough; and second, it didn't explain "why" in terms of alternative DPs and/or non-DP alternatives/paradigms.
Make sure you understand the reason for a suggestion before taking it. Don't do something just because some "authority" said so. If they are a true authority, they can explain why, present multiple alternatives, and why their recommendation is better than those alternatives. "Just trust me" is a yellow alert.
But often it comes down to hunches because it's hard to predict the future of a project or domain requirements. Sometimes you assume it will change in direction X, but instead it changes in direction Y, and then Z.
I've been round-and-round on the topic of "is OOP sub-typing better than switch/case statements?"*, for example, and often it comes down to the how the designer EXPECTS the future to play out. In my experience, they exaggerated the frequency of sub-typing-friendly changes (changes that required the least code rework). I don't know whether the OO sub-type hype made them notice domain changes that fit that code pattern, or if they had formed their view of change patterns before the sub-type hype. I call it as I see it. If one's experience suggests a different change pattern likelihood than my experience, so be it. I document my frequency assumptions based on experience, and try to give practical domain examples.
* C-style languages have a very poor switch/case statement that is error prone. I avoided comparing based on language-specific defects, but did acknowledge that language defects may push one toward sub-types in practice. But my argument was intended for the general case (NPI).
(Score: 2) by PizzaRollPlinkett on Tuesday January 05 2016, @12:23PM
The more I read this, the more I have no idea what the guy is trying to say. He's saying programming should be harder?
(E-mail me if you want a pizza roll!)
(Score: 3, Funny) by Bot on Tuesday January 05 2016, @08:09PM
He's saying we should all switch to perl.
Account abandoned.
(Score: 2) by PizzaRollPlinkett on Tuesday January 05 2016, @08:38PM
I already use Perl. What do I switch to? Version 6? I don't think I like this article at all now.
(E-mail me if you want a pizza roll!)
(Score: 3, Insightful) by RamiK on Tuesday January 05 2016, @12:36PM
Programming is an intellectually challenging task, but luckily we invent tools to make it manageable.
No it's not. SOME programming is intellectually challenging. The vast majority is who-types-the-fastest. And most tools out-there are designed to have the indirections and abstractions written faster rather than solve the hard problems faster\better.
I find that up to a certain point, the intuitive and easy properties of a given language, framework, or library might start to have negative effects.
It's a pedagogical problem. People need to be instructed to actually understand what it is they're doing when it comes to memory allocation and compute. When they're just typing, simpler syntax can trick you into thinking you're doing little when you're actually doing a lot.
From personal experience and from mentoring beginners I noticed that when using tools that allow us to reason within our intuition, anytime we’re faced with some difficulty we feel that we’ve done something wrong. And although we might have the necessary skills to overcome the difficulty, we often start questioning and revising our work. Asking questions about best practices relative to the framework instead of programming our way out.
That's because you have no idea what you're actually doing when using so many layers of abstractions and indirections. This is where you should be opening a debugger and profile the runtime instead of losing yourself in whatever mess the layers of C++, DOM, process isolation and Javascript created. Unfortunately, Javascript was designed so poorly that the amount of junk you'd need to sift through using a debugger is too much. So, Javascript programmers are simply memorizing best practices and trial-and-error their way out of these situations. It's why the browser is so slow and why web-programmers have a terrible reputation: Because most of them isn't programming, they're memorizing.
To be clear: It's to no fault of web-programmers own that they have work like that. They didn't create these tools or languages. They're merely trying to make a living. When experienced system-programmers find themselves needing to work in Javascript, they too abandon all hopes at proper programming and instead just code-monkey their way through it.
A person cannot be expected to hammer a nail with a screwdriver regardless of how good a carpenter s\he is.
compiling...
(Score: 2) by meustrus on Tuesday January 05 2016, @01:54PM
Perhaps that is because Javascript was designed to make it simple and intuitive for the typical person to write a little script for their web page. DOM notwithstanding of course; that mess of complexity is, I suppose, an unfortunate consequence of making HTML simple and intuitive for the typical person to write (and butcher). But something like Javascript's automatic type conversions or its very simple scoping rules are very easy to use. Unfortunately when you try to use Javascript for more real programming problems, using that "intuitive" language puts up barriers to our deeper reasoning.
Don't get me wrong. I wanted to protest the poster's complaints about Javascript. It is absolutely the right thing to do to find a library that does stuff for you. It's also perfectly fair to expect jQuery to do that stuff since it does everything else. And for that matter, RamiK is correct about one crucial thing:
The biggest problems in software are bad decisions that previous programmers made. The overall system is not complicated. Rules like "I am a window with an OK button and a Cancel button" are dead simple and need to stay that way, regardless of what necessary complexity is going on to make it perform well. The key to good programming is to make it so that the next person that reads the code intuitively knows the right way it is supposed to work. It needs to be easy to make changes without being able to anticipate what those changes might be. Solving that problem takes our intuition and our higher reasoning.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 0) by Anonymous Coward on Tuesday January 05 2016, @05:07PM
The vast majority is who-types-the-fastest.
Good luck with your poorly-optimized, unmaintainable mass.
(Score: 2) by tibman on Tuesday January 05 2016, @05:48PM
Not sure where you learned to debug javascript but you shouldn't be dealing with anything server-side and C++ would very much qualify as server-side. Javascript doesn't have abstractions the way most programmers know them. Abstractions typically exist so you can decouple parts of the system. This would let you swap out a database from say MSSQL to MySQL without having to rewrite any of your business logic. Probably the only abstractions i've seen in JS was between chart libraries and also a few for DOM manipulation (nice separation between business logic and ui). But abstractions are pretty rare, that i've seen. Anyways, if you are debugging javascript then the call stack is usually pretty small. Since most javascript is executed from an event (such as a mouse click) then you'll end up with a very specific stack that starts from the event (click) and ends at your breakpoint. Most debuggers put the filename and line number in each stack frame so it's quick to skip over frames you don't care about and get to the bits you do. Files are typically organized like a class unless you are dealing with an external library.
No, that's not very clear. Are you saying C++ developers wrote their language, compilers, linkers, and debuggers?
They don't sound like good programmers to me. Experienced system-programmers perhaps, but not good programmers in general. They should take pride in their work and learn how to improve their programming skill in whatever language they are using. Just abandoning hope is a huge sign of weakness there. I would have a hard time depending on someone like that to do anything that qualified as difficult.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by RamiK on Wednesday January 06 2016, @03:49AM
We're not talking about server-side Javascript. We're talking client-side, in-browser. The kind that spits 20 stacks on mouse click from 20 different scripts that originate from 20 different servers. The kind that you need to debug live-production since you're actually pulling data from all those "clouds" and the bugs don't show up in your test setup network. The kind you have 2000 lines you wrote, 6000 lines team mates wrote, and 40000 lines from external libraries. And they're all being used.
The difference between server and client-JavaScript is the same difference between client-side C++ and server-side C++, only worse. One is the most horrible mess of feature grabbag and design-on-a-whim, while the other is C with Classes. One depends on a couple of GUI libraries, a few file parsing libraries, a couple of database libraries, a few more networking libraries... The other is mostly self-contained with maybe a database and a network library. And many times it's just Boost to do both.
Are you saying C++ developers wrote their language, compilers, linkers, and debuggers?
Again... No compilers or linkers in client-side JavaScript. And yes, SpiderMonkey was written in C++, designed as Scheme, re-designed as Java-looking because of management's pressures, inherited C++ syntax as it was influenced by it's implementation language, and then released. All in the span of 10 days.
And that clean stack you're seeing is the result of 4th generation JavaScript engines. For the first 10-15years since 96, even isolated instances outside the browser were barely traceable. It didn't help Microsoft was sabotaging attempts to fix things while Adobe gave up on fighting MS and forked with Flash's ActionScript.
They don't sound like good programmers to me. Experienced system-programmers perhaps, but not good programmers in general.
Classic write once, never touch it again mentality. If you need good programmers to maintain it, then it's useless. The most you can hope for is experienced programmers. And even that's a luxury in most cases.
Just abandoning hope is a huge sign of weakness there.
Or common sense. The vast majority of projects fails disastrously past deadline after multiple, costly extensions as opposed to dieing in the cradle because someone was too full of himself to admit the tools are broken and the demands were too unrealistic. Maybe if someone was there to yell that the king is naked, earlier on, instead of thinking of how to not show weakness, the company wouldn't have bankrupted and the client wouldn't have been suing.
But hey, that's just loser-talk. You don't get ahead in life working like that. Just keep playing the game. Everything will sort itself out.
compiling...
(Score: 2) by tibman on Wednesday January 06 2016, @03:11PM
A layman reading your posts might think you know what you are talking about. But both you and i know you don't know much at all about javascript programming.
You are saying javascript has file parsing libraries? Javascript cannot access physical files (for security reasons). You are saying javascript has a few networking libraries? Javascript cannot access any hardware to open sockets (for security reasons). JS can make calls to the browser to do standards compliant stuff like opening a websocket but there are no libraries involved. You are saying javascript needs a couple database libraries? I've never even heard of such a thing. If you did connect to a database directly it would be through standard HTTP calls anyways (no special library needed). You are saying javascript depends on a couple GUI libraries? Got me there. Most projects i've encountered have several libs that handle UI stuff. That's no different than C++ though because i couldn't imagine trying to do any screen drawing without a library. Could you imagine writing C++ with a UI that integrates with any desktop environment and not using a library? Madman.
First, shame on you for debugging in live-production : P Second, that is a pain you brought upon yourself. If you cared about your setup then you'd have all your scripts on one server. Third, who cares if your stack has 20 frames in it. You won't care about most of those frames anyways (just like in C++).
That sounds completely normal. Normal for any project in any language i've ever worked on. PHP frameworks or C# sealed classes (booo), it's normal to have external libraries that your code interfaces with. 99% of the time the bug is located in your code, not the library's.
Part of this sounds right. Not the part about a programmer blaming his/her tools. That is probably blame-shifting. But the unrealistic demands are probably the source of projects going over budget and past deadlines. That is language agnostic though. Business pulling dates out of their butt is some sort of sport.
Sorry if i sound defensive about javascript. It's more that people spread FUD. There are plenty of legit javascript complaints that we don't need to invent false ones. I do full stack dev and that requires writing a lot of javascript (about 40% of my code). So when i hear people complaining about javascript it sounds like people first using C/C++ complaining about pointers and memory management.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by RamiK on Saturday January 09 2016, @04:12AM
But both you and i know you don't know much at all about javascript programming.
I'm not a JavaScript programmer. I'm not even a C++ programmer. I might have written JavaScript and C++ productively, but more often than not, I was targeting closed compilers\interpreters, using untrusted debuggers on untrusted kernels running on untrusted CPUs that were emulating CISC but internally doing RISC and counting clock cycles in ways that were never visible to me.
Worse, I have no idea how to reason my coding practices since most of the time they were the result of trial-and-error after profiling bottlenecks and looking at timed charts.
So, take what I have to say with a grain of salt.
file parsing libraries?
As in parsing blocks or streams of data. /proc isn't storage either. Forgive an old Plan 9 user for using the term "file" so liberally. I know it means local storage especially to webdevs.
Also, just for the sake of argument, google "javascript FileReader". It's been in Chrome since 2010 and Firefox since 2012. Though I agree it's insecure and limited for that reason.
Regardless, I consider cookies as persistent file storage.
a few networking libraries?
Protocol implementations are networking libraries. See peerjs.com and freedomjs.org just from the top of the google list. Also, most WebSockets client are libraries. Very few people actually go to the trouble of reimplementing an RFC.
You are saying javascript needs a couple database libraries?
Google "javascript database libraries". This is getting tiresome...
Could you imagine writing C++ with a UI that integrates with any desktop environment and not using a library?
I don't have to. I've written a few targeting both MFC and Xlib using nothing but the headers.
If you cared about your setup then you'd have all your scripts on one server
I don't have the luxury of cherry picking the projects I like to do and how they were written before I came along. And the vast majority of sites nowadays are running crap from allover. Just the social media and advertising scripts alone outnumber anything anyone can debug. Especially as they're almost always obfuscated.
That is probably blame-shifting...full stack dev and that requires writing a lot of javascript (about 40% of my code)
That's the problem right there. If you're writing your own server and client and not working on other people's code predominantly, you're just not coming across the same issues as most JS users.
Look, I'm just old fashioned. I consider myself a language and library user rather than a programmer since I'm just not naive enough to think I have much to argue against people who spend 24/7 writing compilers and interpreters. And still, being a user and judging the language as a product when compared to other languages, I find it poor. It's badly designed and poorly executed and generally just feels uncomfortable to use. I would argue my point further on the usual points you'd find in every such discussion ever made or googled, but considering it's a monopoly on standardized web languages, I honestly don't see the point. Maybe if Brendan Eich wasn't so behind WebAssembly, I would have felt the need to elaborate on the issue.
The only thing I feel is worth saying, is that looking at Python and Golang, I'm sure it's possible, and worthwhile, to do better than JavaScript.
compiling...
(Score: 0) by Anonymous Coward on Tuesday January 05 2016, @11:54PM
Amen! The browser stack (HTML, CSS, JavaScript, DOM) was never intended to mirror most of the UI features users expect from a desktop app. It has since been badgered and beaten into acting like a desktop (badly), but the result is usually ugly bloated fragile code, and a poor user experience.
Time for a new network-friendly UI standard to emerge. The current mess is great job security for those who master this arcane monster, but it's not very satisfying spending all day debugging a goofy scroll-bar, or a window that only half renders, looking like the unfinished Death Star.
(Score: 1, Interesting) by Anonymous Coward on Tuesday January 05 2016, @01:39PM
This sounds a lot like my experience with spell-checking posts to places like soylent. I've found that if I re-read the text out loud I catch *every* error - typos, grammar, homonyms, etc. But if I just read it back "in my head" I miss all kinds of errors. My theory has been that the mental path for reading and speaking is significantly different (and slower) than just reading it silently, even if I try to mentally vocalize each word. Too bad I'm too lazy to read out loud most of the time.
(Score: 2, Interesting) by Anonymous Coward on Tuesday January 05 2016, @05:13PM
A long time ago, I was taught to read things backwards if you're looking for spelling or typographical errors. Your brain is less likely to "autocorrect" the word when it has trouble recognizing the sentence structure.
(Score: 2) by DeathMonkey on Tuesday January 05 2016, @06:44PM
My theory has been that the mental path for reading and speaking is significantly different (and slower) than just reading it silently, even if I try to mentally vocalize each word.
Conversely, if I read a book I tend to retain it much more than if I listen to an audio-book.
(Score: 4, Informative) by tibman on Tuesday January 05 2016, @06:27PM
Yikes man. Turning complex tasks into simpler ones is probably the most powerful thing a developer can do for themselves. Why would you write a socket handler every time you needed to open a connection somewhere? That would be stupid. Do it once and repackage it to be reused later. Application Programmer Interfaces (API) exist for this reason (not solely but it's a big reason). If you wanted to share your solution to a complex problem then you would want to publish the api somewhere. Jquery's API is probably confusing to some people which leads to people just asking about how to do X on a site designed to help solve problems. But no matter what language/library/tool you look at there will be a forum where people are asking silly (to us) questions.
That being said, i have noticed the effect you are describing when someone's auto-complete fails to function. I come from primitive IDEs (text editors, lol) so the auto-complete is largely in the way and damn i dislike IDEs who think pressing space means "select the currently suggested auto-correct item". But i don't necessarily think the effect is a negative one. A tool that someone depends upon suddenly dies then they will suddenly feel like they're driving without a seat-belt on. No big deal.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by darkfeline on Wednesday January 06 2016, @12:10AM
I'm also trying to figure out what the post is saying.
My interpretation is that when you use a language and libraries you are familiar with, you tend to use the same tools and techniques for every problem, even if they could be solved better using a different tool. The biggest example is object-oriented, the proverbial hammer that makes all problems into nails. In recent years we've also had Rails/Django/the web app. Need something done? Write a web app! Never mind that it could be done better as a simple UNIX-style C "do one thing" program. Never mind that it should be a native local app. Never mind that it really should be written in a more scalable language like Golang.
Join the SDF Public Access UNIX System today!