If you write complex code, where the flow path of one function can change the flow path of another function, then you get to multiply each of your tests by the number of other tests. Making each function that you unit test exponentially grow the number of unit tests that you need.
So adding a third function, means adding more test cases to the previous two functions.
Yes, I know this makes no sense to you. Because you've never written a function that isn't self-contained, you've never enjoyed the benefits. Those benefits really hurt your code structure, and your code suffers in terms of speed as well. Oh yeah, and your client benefits, and the project benefits, and your development time improves.
In my world, to my clients, and in my company, those are the priorities. So I do very advanced things (some of which are actually very old things), to get the results that I want even with the sacrifices that you tend to avoid.
It's a very different set of priorities. One with which you likely aren't familiar. Until you've rolled your own company, you'd never have had the opportunity to do so.
You don't understand what I mean when I say quick-converting input types if you think that a compiler can do it for you. I mean taking a three megabyte hash structure, and converting it to the number six in a way that only means something to the isBlank function.
All of the antipatterns with which you're familiar are antipatterns because they make it difficult for others inexperienced with the project to work on the code. That isn't a priority in my world.
implementing an interface in a class presumes the class exists. which means that in your world, at some point, you went through the effort of creating and planning that class. the client didn't ask for a class, they asked for a feature. you didn't build that feature, first you built a class. you got it wrong because two days later the client's going to change the feature drastically, sending you back to the drawing board to replan your entire class.
blank is not an adjective. blank is a subjective description. it's not your word, it's the client's word. so unless you can adapt it in the ways and with the frequency and flexibility that the client uses, you're going to get lost when it comes to client-driven projects.
that fact that you use somewhat formal language for everything doesn't work in client-driven projects. I frequently program with the client on the phone or over my shoulder, describing what they want to see. to be able to make a change, have them see it, then correct it because they've changed their minds, all in a minute, is important in my line of work. it's vital. so the moment the client says "no, I meant really blank", then all of my coding structure needs to flex to accomodate that. if I was using an array, and blank now means every element is blank, then that needs to be a thirty second change, with little or no testing.
in this world, there can't be a spec. I'll lose each and every client if I go down the spec road. They aren't technical, in any sense of the word, not only will they not understand a spec, nor be able to contribute to it, but it'll take up time and I'll lose them as clients before we've even started. I can't charge for the time to work out a spec with them. so all of that time would be wasted money, and hence better spent after the fact.
cognitive compression, again in my world, a world that you don't understand because there's no formal spec, is akin to using one world to cover six others. it's needed in part because the humans involved don't know the other six and hence a close-enough broad-spectrum concept is required, and in part because each of the seven words could have been applicable, and hence they may become applicable. thinking of them all as the equivalent ensures that the code is flexible enough for clients to tweak in all directions. If you've at least understood what I've said, I'm sure you can backtrack the "akin" from words to code.
you've missed the point. I'm not a software engineer. I'm not interested in being employeable. I don't have a resume and haven't for 15 years. I don't get hired. I don't earn a good salary nor any other kind of salary. Oh, and I don't work for anyone.
But you've made your stance very clear. You work for someone else. You spend effort trying to look good on paper. you're worried about losing your job. You're a software engineer.
One day, maybe, if you're not part of the 99% of people who never take any professional risk and responsibility, you'll decide that you're experienced enough to run your own company. And the world becomes a very different place, because you can control absolutely everything.
I develop solutions; it's not about writing proper code, it's about building reliable solutions. Some of those solutions need to work for only a week -- there are short-term problems in business. so some of the code that I produce is incredible crap, because the entire development cycle from idea through completion is an hour.
I don't have a resume because I'm not convincing someone else to hir
didn't originally intend to be. but it kind of turned out that way. my only intention was to point out that tiny functions calling tiny functions that each don't do anything complex can easily be mapped to helpful IDEs that help with trivial structural things; but that properly complex code and experienced programmers don't gain insight by having visualizations and references; we gain insight through rognitive compression -- which is actually thoroughly destroyed by additional information.
about the same as if anyone's supplier ever drops them as a customer. in my case, if I get hit by a bus, someone needs to spend a real amount of time, about a week, to learn enough to do small changes and about three months to take over entirely. Hopefully I'm not the only one here. in your case, the client's just forced to get high school work forever.
yeah, it's a real issue. but it's a real business risk whenever your business depends on a single supplier. it doesn't require a bus to lose a supplier. just one invoice disagreement can be enough. so until you have backup suppliers, you're stuck anyway.
Certainly, I don't have military contracts, and I don't have stock exchange projects. My clients, even the ones that would be hit catastrophically by losing my product and service (with or without me), would suffer for only a few weeks before being almost fully operational again. So that's a business risk that they take.
and it's a valid one. they choose to spend their money on more features and more service, instead of lower risk of loss. I do the same with most of my suppliers as well. In fact, I specifically do it with all of my suppliers that supply products and services that I don't directly resell. Hmm, interesting.
I don't floss, my clients don't back things up, it's a vicious circle.
Dude. you don't know what the word accountable means. When there's a bug, or the code doesn't do what the client thought it would do, do you still get paid? When the client loses money, or doesn't make the money that they expected to make, do you get paid? That's accountability.
You make up some kind of fictitious "sort of signature". My name's on all of my code. It's on the quote, the estimate, the contract, and the invoice. And you'd better believe that my code requires a hefty amount of effort to learn. It's an incredibly steep learning curve to figure out someone else's business model. The question is how much can you do after you've learned that model, whatever it may be.
With your code, high school students can work. That's a great achievement in and of itself. But my clients simply aren't interested in the work that a high school student can comprehend. They won't entrust such inexperienced amateurs with every dollar being made. I really enjoy the fact that some of my customers either generate every dollar of revenue through my code, or account for every dollar of revenue through my code.
oh come on, I assumed you knew how to build logic-based intelligence functions without a maze of if statements. it's never about a different flow path for each input type. it's about quick-converting any input type into a lesser or greater type to match the logic gate. a little bit of basic math takes those logic gates to incredible speeds.
so it becomes more stable, not less. and making a change to the concept of the function means changing all types identically and instantly.
if the client suddenly says that the letter "F" shouldn't be considered, you need to change it in sixty places. I need to change it in one place.
I usually like to think in terms of an office environment. You ask one employee to get you the blank files. Whether or not that gets delegated below you is not your concern. You ask one bottleneck, you get one answer. If you're asking each department head to give you their blank files, then you'll be waiting a long time to get them, and they won't come in together, and they won't all be the same version of blank. someone needs to manage that. that's my isBlank function, bucause it sure as hell ain't my business logic, it isn't my application logic, and because my data is structured according to real-world entities for other reasons, it's not going to be my data logic, just like it won't be my data retrieval logic either.
once you go down the road of objects, I can't help you. enjoy your object hell. enjoy your definitions no where near the actual business logic that you write day to day. enjoy things acting differently from one minute to the next. I won't help you.
but the next time you, as a human not writing code, get handed a food and asked if it's a fruit, you can create a new neuron called NamelessFruit, and then check if it satisfies your seed clause. Me, I'll just look through my index of what makes a fruit a fruit. The way that humans do.
and if you think that for one second, when my client wants that change, that I'm going to extend a class, four files away from where I am, versus just adding a simple if condition to the one place where isBlank is defined, then you're going to expect me to charge my client for the two hours of work that it's going to take to adapt a few megs of code throughout a project, and then to test it, and then to write unit tests for it, and to update existing unit tests.
you'll also, very quickly in my world, have more than three dozen isBlank() functions, all very similar, but completely different. And good luck to you. Humans consider blank to be blank, not a version of blank that's different than a different version of blank. It's called cognitive compression, and it allows for abstract thought. you've killed that, because you now have close to sixty different isBlank functions.
Quite the opposite. a) clients and project requirements change year over year as they grow. So you need to change the function without changing everywhere it's called. b) the more intelligent the function, the more it can do. You, as a human, deal with varied input all the time. That's a part of being intelligent.
For example, something as simple as boolean = isBlank( string ). There are at least a dozen ways that a human being considers a string to be "empty". some of those depend on what that string looks like. certainly "" is empty, and "0" is not. false might be empty. "" might be empty. " " might be empty. "
" might be empty. "
" might be empty. A zero length array would be empty. As would a keyless hash. What about an array where each element is empty.
So what, you're going to have isBlankString() isBlankHTML() isEmptyArray() isBlankArrayElements() isBlankHashKeys() and a dozen others? And then you're going to remember how each is named, how to call each, what they do exactly,...oh right, you're going to have six interfaces to your documentation.
I'm going to have isBlank(). And throughout my code, you'll see isBlank( aStrings ) isBlank( hKeys ) isBlank( myString ) and it'll be way easier to read, way easier to write, and then I'll kick it up to isBlank( oContact ) I'll check the telephone, e-mail, and name, to be certain that a "contact" can actually be "contacted" or I'll call it blank too -- since to a human being, it is. Even though it's a huge structure with a dozen other bits of data. And in six years, when my client wants to consider contacts with a company and position as sufficiently contactable, I'll simply change the definition of isBlank() the way that humans do.
My client's world isn't data-centric. It's business centric. So my logic functions are similarly so. As long as I keep them in-line with the client's business model, life is amazingly easy. And different for each client.
As for planning things out in advance, I plan for my client's business to grow, and hence change drastically. What do you plan for? A string remaining a string forever and never becoming a hash down the road? Everything becomes a hash eventually. Or do you plan to do all of the work for the hash from the start? And making it take six days to do something that only requires one day now, and may be thrown out long before that part is ever upgraded.
It's a very different way of thinking. That's what I charge for.
Unit testing isn't worse, but it's equally bad. If you can predict every combination of parameters relevant to the function, then your unit tests simply tell you when you broke your own function. I don't need help changing three lines of code. That was never the difficult part. I need help conceiving of complicated structures and not missing a given element.
If I could write the unit tests properly, I didn't really need them. So you wind up needing to test your unit tests for conseptual validity. It's turtles all the way down.
The whole point of abstract programming is to think abstractly. The moment you lose that, you lose the ability to do anything advanced. That's the skill. It's not about typing, and it's not about executing it in your head. About specifically about not executing it in your head.
Ah, static typing, that would be first year high school. Well done. Is your diploma mounted in your bedroom?
You might want to try intelligent functions. Functions with multiple optional parameters, and functions that take entire structures, consider environmental parameters, and maybe, just maybe, make some actual decisions on behalf of someone earning seven figures annually.
Let me know when you've written a function that tells a C.E.O. which three of thirty employees should be fired. That's a period, by the way. You get to figure out what that means, how it should work, and what to consider. Then you can tell me how simple your logic becomes.
Now, if you had said "learn about neural networks sometime", then at least you'd have been in first-year university.
Why don't you show me some code that no high school student could understand, no university student could write, and for which no employee could ever be accountable. Then you'll see what I do for a living.
...that's scripting. Any time you can gain insight into your code by seeing variable values substituted for names, (which used to be called watched variables long ago), your code just isn't advanced enough to be doing anything legitimate. That's great and all when you're learning to program in school, and you were asked to use a few functions to make something happen. But that's not programming.
When, professionally, I write my own function, I can't make judgements based on actual variable values! A given function is called from at least three dozen places, and here's the kicker, in more than three dozen different ways. That not only means that flow paths change, but the actual value of a parameter can have drastic effects on what the function actually does. I don't mean that 3 becomes 30 and 4 becomes 40. I mean 3 becomes apple and 4 becomes an array of database results.
The entire idea of advanced programming is to use variable instead of actual values because programming is more powerful than markup. Because I can bring real intelligence to a function's operation.
And if I dared to modify a function based on a set of run-time values for one of those scenarios, I'd risk instantly breaking every other run-time scenario where that function is being called.
Now, if Light Table, or some IDE wants to show me every time my function is being called throughout my entire project, with every distinct set of parameters that it's ever received, and allow me to pair down the ones that I say are structurally identical, then yeah, that would have merit. Of course, it would be showing me about a hundred different scenarios for my one function, and would be based on weird run-time and user-input cases that simply couldn't be reproduced without actually running my entire project, so it would be impossible to simulate once I make one change to any other function anywhere else in my project.
Making things like this excellent academic learning tools, and nothing else. It simply removes the fundamental abstraction that is programming, and replaces it with information that I didn't need. I don't need documentation for a language that I use professionally. And I don't need to see the functions called by my function. Not only am I not able to comfortably change those sub-functions, but there are going to be at least fifty of those sub-functions if my code does anything impressive at all.
And you've consumed half of my screen real-estate.
Once again, this is not a public service nor a public right. If a private company like kickstarter doesn't or can't or chooses not to support an action which they believe will be ineffective (i.e. unprofitable), then that's the end of the game. There's nothing wrong with that.
As for the conclusion that therefore she cannot growdfund anything, that's just stupid. There are other sites, and she can always roll her own. She's already got more publicity than I've ever had. Boo hoo that this one supplyer won't work for you. Move on.
None of my cars lock the steering wheel without turning the wheel, but I agree with you that neutral is a better idea than off, not that ACC would be too difficult, in a case as described. As always, train the driver.
I don't get it. If my car were flying down the highway, accellerator jammed, I turn off the engine. If I don't want to lose power braking, I shift into neutral. The engine can blow in neutral, rev-limiter might save it, I brake as usual.
So who learned to drive a car, and didn't learn to stop driving a car? Since my first highway driving lesson included being taught to confidently restart the engine at 120 kph in the event that anything fails ever. I was 16 then. And my car was worth $4'000. Perhaps I'd have been willing to crash a $90'000 car in a fiery death.
because it's basically direct-to-graphics output. It's closer to logo than to C, as it's little more than DOM manipulation and you get to see the results directly.
I'd say perl, because it's my favourite, but there are too many advanced structure concepts and hidden context sensitivities that don't make sense until you've struggled without them.
my first was logo, followed by turing, followed by A.I. bugs. Actually, the old 2D A.I. Bugs is also a pretty great first one. Program an insect to look for other insects and fire missles. basically the software-only version of battle bots. might be good, I don't know. but it's very simplistic with direct visual output again.
I'm sorry, I'd forgotten about the google business service where they sometimes may or may not show your ad that you sometimes may or may not have paid for at random intervals to random groups of people in random places. Now that's commitment. Tell me, about what would businesses complain?
And again, that's marketing, or advertising. It's a crap-shoot in the best of cases. And it's not something on which businesses rely on a daily basis.
Microsoft's entire market, especially these days, is in the business sector. When they misstep, professionals complain that they are losing real dollars. When apple, google, or facebook missteps, those markets are recreational. They've built entire businesses on the concept that users are just having fun. So if your fun breaks, or changes, meh it's no big deal. So there's no one left to complain about anything significant.
That's how you know that no one's really using those things for anything legitimate. Business keeps on going because business was never depending on it in the first place.
Yeah, great idea. Take the very fastest communication that we have on the entire planet, and replace it with the absolute slowest communication we have on the planet. Great idea. And with it, more complexity, more caches, more lookup tables, and more things to go wrong.
The best part is that it's totally unbalanced. Internet protocols are based on a network that's ever-changing and totally unreliable. The bus, on the other hand, is best on total reliability and static.
I'd have thought that a pool concept, or a mailbox metaphor, or a message board analog would have been more appropriate. Something where streams are naturally quantized and sending is unpaired from receiving. Where a recipient can operate at it's own rate uncommon to the sender.
You know, like typical linux interactive sockets, for example. But what do I know.
yeah, but we're talking here about: a) a medical device b) being updated occasionally c) as opposed to surgery d) to deal with an injury e) that can kill you
like I said, light, even visible light works. vibrations also work. and anything blocked by clothing works. or hey, here's a bright idea, uni-directional wireless ought to be as easy as a headlight. require line-of-sight, which won't be reliable when a person is moving. or a hair-antenna as a contact device. one blue hair. or go full wireless but require a vibrational authentication. make me punch myself to authenticate an update. or make me use a device with a set vibrational authentication pattern -- like any cellphone could be made to do. none of those require any additional power. certainly not a vibration sensor, and certainly not IR.
Who needs to update their heart from 300 feet away? One of the articles discusses encryption as a solution -- because the person is an idiot. My heart doesn't have any encryption. It has one very important security feature: it doesn't talk to devices 300 feet away.
It's very easy to screw with my organs, you come up to me and you hit them. It's really easy.
So who decided that an insulin pump needed full-range wireless connectivity? How about 3 inches. 3 inches would have been great. It's already refilled by a seringe. Ignoring, for the moment, that a seringe-like probe could have updated it without anything being wireless, a simple short-range induction or vibrational signal, or even IR -- actually, IR would have been fantastic because it would have been obscured by clothing, a security device that has resulted in every doctor everywhere asking patients to disrobe, and then leaving for another random amount of time.
but no, let's use a technology designed for long-distance communication. We talk to space telescopes and voyager probes this way, so it clearly makes sense that implanted devices be accessed this same way -- you know, in case voyager wants to screw with us.
Living in Toronto, the most culturally diverse place in the world, I expected this article to be quite offensive. Sure a few word choices were a little off-putting (amulet comes to mind), and voting for anyone without checking them out sounds stupid regarding any politician, but mostly it's a parent's life experiences being propegated to his own children. (publicly assisting similar parents is neither here nor there.)
It doesn't need to be a general truth in order for a parent to teach it to a child. It simply needs to be a parent's experience. There are plenty of life lessons that I've learned, from my own experiences, that I know full well don't hold true in general. But they seem to hold true in my own every-day life. So yeah, if I had a child, I'd teach them to avoid the problems that happen in my life. Sure they'll need to learn where that does and doesn't hold true for their own, but that's the case with everything.
I can't say that I agree or disagree with the majority of the article's points. I'm in a different country, in a very different lifestyle, and I've certainly seen multiple sides described. But I also keep my own statistics, often just for fun.
For example, I've been counting, and on the road while driving, when I've said "that guy doesn't know how to drive" or I've been cut off by another driver, I've counted the demographics. I can say with certainty that there are approximately 40% more female than male, for example. Again, my idea of what's a bad driver doesn't mean anything at all.
But about six months ago, I experienced one of those rare odd-ballls. For the first time in my 20 years of driving, the poor driver was a young black man (age 35-ish). I found it stunning as it was quite the outlier to my numbers.
So would I tell my child to trust black drivers and to not trust female drivers (as per my general observations)? Well, I'd be silly not to share my data with my offspring. Just the same, I wouldn't object to their observations contradicting my own.
Given that we've already run out of copper, oil, air, water, computers are the size of buildings, travel is expensive, and cars fly.
But I do agree with one perspective. It'll take a growth spurt like over-population to encourage a lunar colony. And it'll take at least one resource shortage to encourage mining an asteroid.
But we can always kill two birds with one stone. In 2029, maybe we'll get lucky. A meteor can impact earth, killing a few billion people and providing new resources. Gotta love instant solutions to complex problems.
Because configuring your existing SQL server to not run multiple queries wouldn't solve 90% of the problems, and connecting through a user that doesn't have DROP would solve the other 10%.
I love smart solutions for dumb people, they're exactly the same as dumb solutions for smart people. Maybe that's the conservation of dumbness law. Even the name fits the law.
Slashdot Mirror
If you write complex code, where the flow path of one function can change the flow path of another function, then you get to multiply each of your tests by the number of other tests. Making each function that you unit test exponentially grow the number of unit tests that you need.
So adding a third function, means adding more test cases to the previous two functions.
Yes, I know this makes no sense to you. Because you've never written a function that isn't self-contained, you've never enjoyed the benefits. Those benefits really hurt your code structure, and your code suffers in terms of speed as well. Oh yeah, and your client benefits, and the project benefits, and your development time improves.
In my world, to my clients, and in my company, those are the priorities. So I do very advanced things (some of which are actually very old things), to get the results that I want even with the sacrifices that you tend to avoid.
It's a very different set of priorities. One with which you likely aren't familiar. Until you've rolled your own company, you'd never have had the opportunity to do so.
You don't understand what I mean when I say quick-converting input types if you think that a compiler can do it for you. I mean taking a three megabyte hash structure, and converting it to the number six in a way that only means something to the isBlank function.
All of the antipatterns with which you're familiar are antipatterns because they make it difficult for others inexperienced with the project to work on the code. That isn't a priority in my world.
implementing an interface in a class presumes the class exists. which means that in your world, at some point, you went through the effort of creating and planning that class. the client didn't ask for a class, they asked for a feature. you didn't build that feature, first you built a class. you got it wrong because two days later the client's going to change the feature drastically, sending you back to the drawing board to replan your entire class.
blank is not an adjective. blank is a subjective description. it's not your word, it's the client's word. so unless you can adapt it in the ways and with the frequency and flexibility that the client uses, you're going to get lost when it comes to client-driven projects.
that fact that you use somewhat formal language for everything doesn't work in client-driven projects. I frequently program with the client on the phone or over my shoulder, describing what they want to see. to be able to make a change, have them see it, then correct it because they've changed their minds, all in a minute, is important in my line of work. it's vital. so the moment the client says "no, I meant really blank", then all of my coding structure needs to flex to accomodate that. if I was using an array, and blank now means every element is blank, then that needs to be a thirty second change, with little or no testing.
in this world, there can't be a spec. I'll lose each and every client if I go down the spec road. They aren't technical, in any sense of the word, not only will they not understand a spec, nor be able to contribute to it, but it'll take up time and I'll lose them as clients before we've even started. I can't charge for the time to work out a spec with them. so all of that time would be wasted money, and hence better spent after the fact.
cognitive compression, again in my world, a world that you don't understand because there's no formal spec, is akin to using one world to cover six others. it's needed in part because the humans involved don't know the other six and hence a close-enough broad-spectrum concept is required, and in part because each of the seven words could have been applicable, and hence they may become applicable. thinking of them all as the equivalent ensures that the code is flexible enough for clients to tweak in all directions. If you've at least understood what I've said, I'm sure you can backtrack the "akin" from words to code.
you've missed the point. I'm not a software engineer. I'm not interested in being employeable. I don't have a resume and haven't for 15 years. I don't get hired. I don't earn a good salary nor any other kind of salary. Oh, and I don't work for anyone.
But you've made your stance very clear. You work for someone else. You spend effort trying to look good on paper. you're worried about losing your job. You're a software engineer.
One day, maybe, if you're not part of the 99% of people who never take any professional risk and responsibility, you'll decide that you're experienced enough to run your own company. And the world becomes a very different place, because you can control absolutely everything.
I develop solutions; it's not about writing proper code, it's about building reliable solutions. Some of those solutions need to work for only a week -- there are short-term problems in business. so some of the code that I produce is incredible crap, because the entire development cycle from idea through completion is an hour.
I don't have a resume because I'm not convincing someone else to hir
didn't originally intend to be. but it kind of turned out that way. my only intention was to point out that tiny functions calling tiny functions that each don't do anything complex can easily be mapped to helpful IDEs that help with trivial structural things; but that properly complex code and experienced programmers don't gain insight by having visualizations and references; we gain insight through rognitive compression -- which is actually thoroughly destroyed by additional information.
about the same as if anyone's supplier ever drops them as a customer. in my case, if I get hit by a bus, someone needs to spend a real amount of time, about a week, to learn enough to do small changes and about three months to take over entirely. Hopefully I'm not the only one here. in your case, the client's just forced to get high school work forever.
yeah, it's a real issue. but it's a real business risk whenever your business depends on a single supplier. it doesn't require a bus to lose a supplier. just one invoice disagreement can be enough. so until you have backup suppliers, you're stuck anyway.
Certainly, I don't have military contracts, and I don't have stock exchange projects. My clients, even the ones that would be hit catastrophically by losing my product and service (with or without me), would suffer for only a few weeks before being almost fully operational again. So that's a business risk that they take.
and it's a valid one. they choose to spend their money on more features and more service, instead of lower risk of loss. I do the same with most of my suppliers as well. In fact, I specifically do it with all of my suppliers that supply products and services that I don't directly resell. Hmm, interesting.
I don't floss, my clients don't back things up, it's a vicious circle.
Maybe that's why I don't take the bus.
Dude. you don't know what the word accountable means. When there's a bug, or the code doesn't do what the client thought it would do, do you still get paid? When the client loses money, or doesn't make the money that they expected to make, do you get paid? That's accountability.
You make up some kind of fictitious "sort of signature". My name's on all of my code. It's on the quote, the estimate, the contract, and the invoice. And you'd better believe that my code requires a hefty amount of effort to learn. It's an incredibly steep learning curve to figure out someone else's business model. The question is how much can you do after you've learned that model, whatever it may be.
With your code, high school students can work. That's a great achievement in and of itself. But my clients simply aren't interested in the work that a high school student can comprehend. They won't entrust such inexperienced amateurs with every dollar being made. I really enjoy the fact that some of my customers either generate every dollar of revenue through my code, or account for every dollar of revenue through my code.
That's what I'm maintaining.
oh come on, I assumed you knew how to build logic-based intelligence functions without a maze of if statements. it's never about a different flow path for each input type. it's about quick-converting any input type into a lesser or greater type to match the logic gate. a little bit of basic math takes those logic gates to incredible speeds.
so it becomes more stable, not less. and making a change to the concept of the function means changing all types identically and instantly.
if the client suddenly says that the letter "F" shouldn't be considered, you need to change it in sixty places. I need to change it in one place.
I usually like to think in terms of an office environment. You ask one employee to get you the blank files. Whether or not that gets delegated below you is not your concern. You ask one bottleneck, you get one answer. If you're asking each department head to give you their blank files, then you'll be waiting a long time to get them, and they won't come in together, and they won't all be the same version of blank. someone needs to manage that. that's my isBlank function, bucause it sure as hell ain't my business logic, it isn't my application logic, and because my data is structured according to real-world entities for other reasons, it's not going to be my data logic, just like it won't be my data retrieval logic either.
once you go down the road of objects, I can't help you. enjoy your object hell. enjoy your definitions no where near the actual business logic that you write day to day. enjoy things acting differently from one minute to the next. I won't help you.
but the next time you, as a human not writing code, get handed a food and asked if it's a fruit, you can create a new neuron called NamelessFruit, and then check if it satisfies your seed clause. Me, I'll just look through my index of what makes a fruit a fruit. The way that humans do.
and if you think that for one second, when my client wants that change, that I'm going to extend a class, four files away from where I am, versus just adding a simple if condition to the one place where isBlank is defined, then you're going to expect me to charge my client for the two hours of work that it's going to take to adapt a few megs of code throughout a project, and then to test it, and then to write unit tests for it, and to update existing unit tests.
you'll also, very quickly in my world, have more than three dozen isBlank() functions, all very similar, but completely different. And good luck to you. Humans consider blank to be blank, not a version of blank that's different than a different version of blank. It's called cognitive compression, and it allows for abstract thought. you've killed that, because you now have close to sixty different isBlank functions.
Quite the opposite. a) clients and project requirements change year over year as they grow. So you need to change the function without changing everywhere it's called. b) the more intelligent the function, the more it can do. You, as a human, deal with varied input all the time. That's a part of being intelligent.
For example, something as simple as boolean = isBlank( string ). There are at least a dozen ways that a human being considers a string to be "empty". some of those depend on what that string looks like. certainly "" is empty, and "0" is not. false might be empty. "" might be empty. " " might be empty. "
" might be empty. "
" might be empty. A zero length array would be empty. As would a keyless hash. What about an array where each element is empty.
So what, you're going to have isBlankString() isBlankHTML() isEmptyArray() isBlankArrayElements() isBlankHashKeys() and a dozen others? And then you're going to remember how each is named, how to call each, what they do exactly, ...oh right, you're going to have six interfaces to your documentation.
I'm going to have isBlank(). And throughout my code, you'll see isBlank( aStrings ) isBlank( hKeys ) isBlank( myString ) and it'll be way easier to read, way easier to write, and then I'll kick it up to isBlank( oContact ) I'll check the telephone, e-mail, and name, to be certain that a "contact" can actually be "contacted" or I'll call it blank too -- since to a human being, it is. Even though it's a huge structure with a dozen other bits of data. And in six years, when my client wants to consider contacts with a company and position as sufficiently contactable, I'll simply change the definition of isBlank() the way that humans do.
My client's world isn't data-centric. It's business centric. So my logic functions are similarly so. As long as I keep them in-line with the client's business model, life is amazingly easy. And different for each client.
As for planning things out in advance, I plan for my client's business to grow, and hence change drastically. What do you plan for? A string remaining a string forever and never becoming a hash down the road? Everything becomes a hash eventually. Or do you plan to do all of the work for the hash from the start? And making it take six days to do something that only requires one day now, and may be thrown out long before that part is ever upgraded.
It's a very different way of thinking. That's what I charge for.
Unit testing isn't worse, but it's equally bad. If you can predict every combination of parameters relevant to the function, then your unit tests simply tell you when you broke your own function. I don't need help changing three lines of code. That was never the difficult part. I need help conceiving of complicated structures and not missing a given element.
If I could write the unit tests properly, I didn't really need them. So you wind up needing to test your unit tests for conseptual validity. It's turtles all the way down.
The whole point of abstract programming is to think abstractly. The moment you lose that, you lose the ability to do anything advanced. That's the skill. It's not about typing, and it's not about executing it in your head. About specifically about not executing it in your head.
uhuh, you didn't read. I said three from thirty. I don't see thirty being considered.
Ah, static typing, that would be first year high school. Well done. Is your diploma mounted in your bedroom?
You might want to try intelligent functions. Functions with multiple optional parameters, and functions that take entire structures, consider environmental parameters, and maybe, just maybe, make some actual decisions on behalf of someone earning seven figures annually.
Let me know when you've written a function that tells a C.E.O. which three of thirty employees should be fired. That's a period, by the way. You get to figure out what that means, how it should work, and what to consider. Then you can tell me how simple your logic becomes.
Now, if you had said "learn about neural networks sometime", then at least you'd have been in first-year university.
Why don't you show me some code that no high school student could understand, no university student could write, and for which no employee could ever be accountable. Then you'll see what I do for a living.
...that's scripting. Any time you can gain insight into your code by seeing variable values substituted for names, (which used to be called watched variables long ago), your code just isn't advanced enough to be doing anything legitimate. That's great and all when you're learning to program in school, and you were asked to use a few functions to make something happen. But that's not programming.
When, professionally, I write my own function, I can't make judgements based on actual variable values! A given function is called from at least three dozen places, and here's the kicker, in more than three dozen different ways. That not only means that flow paths change, but the actual value of a parameter can have drastic effects on what the function actually does. I don't mean that 3 becomes 30 and 4 becomes 40. I mean 3 becomes apple and 4 becomes an array of database results.
The entire idea of advanced programming is to use variable instead of actual values because programming is more powerful than markup. Because I can bring real intelligence to a function's operation.
And if I dared to modify a function based on a set of run-time values for one of those scenarios, I'd risk instantly breaking every other run-time scenario where that function is being called.
Now, if Light Table, or some IDE wants to show me every time my function is being called throughout my entire project, with every distinct set of parameters that it's ever received, and allow me to pair down the ones that I say are structurally identical, then yeah, that would have merit. Of course, it would be showing me about a hundred different scenarios for my one function, and would be based on weird run-time and user-input cases that simply couldn't be reproduced without actually running my entire project, so it would be impossible to simulate once I make one change to any other function anywhere else in my project.
Making things like this excellent academic learning tools, and nothing else. It simply removes the fundamental abstraction that is programming, and replaces it with information that I didn't need. I don't need documentation for a language that I use professionally. And I don't need to see the functions called by my function. Not only am I not able to comfortably change those sub-functions, but there are going to be at least fifty of those sub-functions if my code does anything impressive at all.
And you've consumed half of my screen real-estate.
Once again, this is not a public service nor a public right. If a private company like kickstarter doesn't or can't or chooses not to support an action which they believe will be ineffective (i.e. unprofitable), then that's the end of the game. There's nothing wrong with that.
As for the conclusion that therefore she cannot growdfund anything, that's just stupid. There are other sites, and she can always roll her own. She's already got more publicity than I've ever had. Boo hoo that this one supplyer won't work for you. Move on.
None of my cars lock the steering wheel without turning the wheel, but I agree with you that neutral is a better idea than off, not that ACC would be too difficult, in a case as described. As always, train the driver.
I don't get it. If my car were flying down the highway, accellerator jammed, I turn off the engine. If I don't want to lose power braking, I shift into neutral. The engine can blow in neutral, rev-limiter might save it, I brake as usual.
So who learned to drive a car, and didn't learn to stop driving a car? Since my first highway driving lesson included being taught to confidently restart the engine at 120 kph in the event that anything fails ever. I was 16 then. And my car was worth $4'000. Perhaps I'd have been willing to crash a $90'000 car in a fiery death.
because it's basically direct-to-graphics output. It's closer to logo than to C, as it's little more than DOM manipulation and you get to see the results directly.
I'd say perl, because it's my favourite, but there are too many advanced structure concepts and hidden context sensitivities that don't make sense until you've struggled without them.
my first was logo, followed by turing, followed by A.I. bugs. Actually, the old 2D A.I. Bugs is also a pretty great first one. Program an insect to look for other insects and fire missles. basically the software-only version of battle bots. might be good, I don't know. but it's very simplistic with direct visual output again.
for the love of code, don't ever go to lisp.
I'm sorry, I'd forgotten about the google business service where they sometimes may or may not show your ad that you sometimes may or may not have paid for at random intervals to random groups of people in random places. Now that's commitment. Tell me, about what would businesses complain?
And again, that's marketing, or advertising. It's a crap-shoot in the best of cases. And it's not something on which businesses rely on a daily basis.
Microsoft's entire market, especially these days, is in the business sector. When they misstep, professionals complain that they are losing real dollars. When apple, google, or facebook missteps, those markets are recreational. They've built entire businesses on the concept that users are just having fun. So if your fun breaks, or changes, meh it's no big deal. So there's no one left to complain about anything significant.
That's how you know that no one's really using those things for anything legitimate. Business keeps on going because business was never depending on it in the first place.
Yeah, great idea. Take the very fastest communication that we have on the entire planet, and replace it with the absolute slowest communication we have on the planet. Great idea. And with it, more complexity, more caches, more lookup tables, and more things to go wrong.
The best part is that it's totally unbalanced. Internet protocols are based on a network that's ever-changing and totally unreliable. The bus, on the other hand, is best on total reliability and static.
I'd have thought that a pool concept, or a mailbox metaphor, or a message board analog would have been more appropriate. Something where streams are naturally quantized and sending is unpaired from receiving. Where a recipient can operate at it's own rate uncommon to the sender.
You know, like typical linux interactive sockets, for example. But what do I know.
yeah, but we're talking here about: a) a medical device b) being updated occasionally c) as opposed to surgery d) to deal with an injury e) that can kill you
I think that's ok.
like I said, light, even visible light works. vibrations also work. and anything blocked by clothing works. or hey, here's a bright idea, uni-directional wireless ought to be as easy as a headlight. require line-of-sight, which won't be reliable when a person is moving. or a hair-antenna as a contact device. one blue hair. or go full wireless but require a vibrational authentication. make me punch myself to authenticate an update. or make me use a device with a set vibrational authentication pattern -- like any cellphone could be made to do. none of those require any additional power. certainly not a vibration sensor, and certainly not IR.
anything but nothing.
Who needs to update their heart from 300 feet away? One of the articles discusses encryption as a solution -- because the person is an idiot. My heart doesn't have any encryption. It has one very important security feature: it doesn't talk to devices 300 feet away.
It's very easy to screw with my organs, you come up to me and you hit them. It's really easy.
So who decided that an insulin pump needed full-range wireless connectivity? How about 3 inches. 3 inches would have been great. It's already refilled by a seringe. Ignoring, for the moment, that a seringe-like probe could have updated it without anything being wireless, a simple short-range induction or vibrational signal, or even IR -- actually, IR would have been fantastic because it would have been obscured by clothing, a security device that has resulted in every doctor everywhere asking patients to disrobe, and then leaving for another random amount of time.
but no, let's use a technology designed for long-distance communication. We talk to space telescopes and voyager probes this way, so it clearly makes sense that implanted devices be accessed this same way -- you know, in case voyager wants to screw with us.
Living in Toronto, the most culturally diverse place in the world, I expected this article to be quite offensive. Sure a few word choices were a little off-putting (amulet comes to mind), and voting for anyone without checking them out sounds stupid regarding any politician, but mostly it's a parent's life experiences being propegated to his own children. (publicly assisting similar parents is neither here nor there.)
It doesn't need to be a general truth in order for a parent to teach it to a child. It simply needs to be a parent's experience. There are plenty of life lessons that I've learned, from my own experiences, that I know full well don't hold true in general. But they seem to hold true in my own every-day life. So yeah, if I had a child, I'd teach them to avoid the problems that happen in my life. Sure they'll need to learn where that does and doesn't hold true for their own, but that's the case with everything.
I can't say that I agree or disagree with the majority of the article's points. I'm in a different country, in a very different lifestyle, and I've certainly seen multiple sides described. But I also keep my own statistics, often just for fun.
For example, I've been counting, and on the road while driving, when I've said "that guy doesn't know how to drive" or I've been cut off by another driver, I've counted the demographics. I can say with certainty that there are approximately 40% more female than male, for example. Again, my idea of what's a bad driver doesn't mean anything at all.
But about six months ago, I experienced one of those rare odd-ballls. For the first time in my 20 years of driving, the poor driver was a young black man (age 35-ish). I found it stunning as it was quite the outlier to my numbers.
So would I tell my child to trust black drivers and to not trust female drivers (as per my general observations)? Well, I'd be silly not to share my data with my offspring. Just the same, I wouldn't object to their observations contradicting my own.
Given that we've already run out of copper, oil, air, water, computers are the size of buildings, travel is expensive, and cars fly.
But I do agree with one perspective. It'll take a growth spurt like over-population to encourage a lunar colony. And it'll take at least one resource shortage to encourage mining an asteroid.
But we can always kill two birds with one stone. In 2029, maybe we'll get lucky. A meteor can impact earth, killing a few billion people and providing new resources. Gotta love instant solutions to complex problems.
Because configuring your existing SQL server to not run multiple queries wouldn't solve 90% of the problems, and connecting through a user that doesn't have DROP would solve the other 10%.
I love smart solutions for dumb people, they're exactly the same as dumb solutions for smart people. Maybe that's the conservation of dumbness law. Even the name fits the law.