Disagree. This would be MUCH clearer with better names. $file should be $filename. @file should be @fileLines or @fileData, to show that it holds the data from the file. %file should be something either naming the type of data used in it, or for a very generic function like that named to show that its the result of the operation. This would not pass a code review in any organization I've ever been part of.
Yes, because nobody who writes in any other language indents for style reasons. Oh wait, EVERYONE does.
Meanwhile Python has actively cost me at least 2 weeks of time tracking down bugs that ended up being due to mixing of tabs and spaces causing incorrect nesting levels, but nobody could see it because it looked ok on the screen. No other language has ever caused me that.
Until Python loses that feature, its a complete non-starter to a lot of programmers. I despise perl, but I'd rather deal with line noise syntax and lack of an object model than python's whitespace issues.
Perl 6 has been just around the corner for 13 years. At this point do you really think it will ever actually be finished? If they were actually serious about it it would have come out a decade ago.
I don't find constant pair programming improves standards. I find it slows development to a crawl while leading to developers who are either mentally checked out or goofing around most of the day. Or depending on your developers, arguing over inanities. Or they just leave- I wouldn't stay at a job where I was going to literally have someone standing over my shoulder telling me what to do all day.
Code reviews are good, but you have the same problem as the OP does- you have to convince people not to half ass them. Its quite easy to fall into either rubber stamping (especially if you're busy), or arguing over trivial matters. Like any other tactic it takes people committed to quality and getting things done to make it work.
In the end, there's no substitute for developers who take pride in their work. You either have them or you don't. If you can't convince them to start taking it, no tool or technique will improve things.
Why the hell should a compiler know what JSON is? A compilers job is to turn code into machine or bytecode. Giving it more intelligence is a mistake. Generate the code maybe, but not as part of the compiler.
I'm going to disagree on easier to debug, because its impossible to step through the process of generation, which tends to be where the mistake is. It also means not all of your code is in source control, because the compiler itself becomes part of your code. I dislike the efficiency of runtime generation, but its more transparent because the generation code is part of your source.
No, that kind of stuff is WAY, WAY outside the scope of a compiler. Why the hell would a compiler even know JSON exists? You can argue its the job of a preprocessor or code generation utility run as part of your build process and you'd have a point. The advantage of using reflection is that all your code is in your source code and checked it- with preprocessing tools or code generation you're generating code at compile time which breaks a lot of tools and makes debugging errors much more difficult.
Its major use is to avoid busy work for the programmer. An example is ORM where the program can analyze what fields a class has and figure out what data types those fields are and build sql querries from it. Another example is xml/json parsing, where you can pass in a json string and a class definition and have it match all of the fields in the json to members in the class. You can spend 15 minutes writing annoying boilerplate code or 15 seconds making 1 method call.
Wrong question. How many people love eating, don't want to be fat, and think that this could possibly be a good or healthy idea? And want to deal with the disposal and cleanup of the pumped material? I love eating and it would be great to lose 100 pounds, but I know that this isn't safe and is actually counter-productive.
It isn't even allowing me to register. Too bad- I have an app that automatically sends text messages to voice input/output mode when driving that would be MUCH nicer if it could interface with the car's speed detection than my rough estimates (for those interested, Text Soundly on the Google Play store). Not going to happen if I can't even download the SDK.
Yes we want pixel perfect rendering. Or rather, the web designers do. That's why HTML and CSS are the horrific combination they are today, and why web designers spend so much time tweaking things so they look exactly the same on all browsers. It's not what HTML and CSS were designed for, but it's how its used today. Time to move on and add a new language that uses it well.
Viewing source in the browser has some benefits. One of the major problems it has is that the browser then has to include an interpreter, forcing the developer to use the languages the browser knows. Which basically forces them to use only javascript. Moving to byte code would allow the program to be written in any language, a HUGE gain.
No, it is *VERY* concise. Specific words have an extremely specific meaning, and new concepts are defined in detail. That's why it reads the way it does. Writing it in plain english would take 5 or 6 times the amount of space to mean the same thing.
But conciseness isn't always the right goal. Take legalese- it's very concise. That's why its used. It isn't readable. Or take perl- people can do an awful lot in 1 line, but nobody can understand it without really studying it. Doing it in 5 or 6 lines instead can be much more readable, and thus maintainable.
Namespaces are pretty trivial to get around the lack of, C programmers have done it for 40 years and there's plenty of large systems written in it. It just takes discipline- prepend your function names with the module name. If you're in namespace window and have a function getHeight, you write it as window_getHeight. It takes a little bit of discipline, but not that much.
The real problem with web programming being unmaintainable is a combination of several factors, pretty much in this order:
1)Web programmers tend to be lower skill programmers. This is for historical reasons- when web apps didn't do much, good programmers wanted to work on more complex problems not just write a GUI for the hundredth time. It tends to be considered an entry level job, pays less,and lacks respect among programmers. Also, the lower barriers to entry on web programming means a lot of self-taught people enter that part of the field, who never really learn CS or software engineering.
2)There's a hack it and get it done mentality to web programmers. This comes from the quick cycle nature of web programming (which tends to be very visual based and small changes are easy to make on the fly) and the abundance of "agile" methodologies which tend to lack in design. Its made worse by how poor a markup language html/css are for what we try to make them do today and the amount of hacking that's necessary to get around browser incompatibilities.
3)The entire AJAX and framework of web programming is wrong. It was a quick hack added so that you could make dynamic apps using existing technologies without major changes to clients. But its layered hack upon hack upon hack. We really need to scrap it all and come up with a web application programming stack- a new markup language that's meant to do pixel perfect rendering (HTML is not, but its used that way), an HTTP replacement that's stateful rather than stateless, a cleaner way of sending data back and forth from the server. But if you write on top of an ugly platform, you're going to get ugly code.
4)Language issues. Javascript was never a good language- hell, you can tell that from the fact it's very name was a blatant marketing maneuver. Lack of a good object model is a real problem. Ideally you would want to be able to use any language here- maybe it's time to start delivering apps as byte code binary so the actual app can be written in whatever the programmer thinks best.
Unfortunately the last two of those would require fixes by the major browser vendors, the first two would take a decade of culture change to fix. So its going to continue to suck for a while.
The problem with a bluetooth keyboard is if I'm going to that trouble, why don't I just use a laptop? But yes, if you were going to try this for real a bluetooth keyboard is a must.
Swiftkey is an n-gram model where there's a probability of different words based on the previous words in the sentence. They got it to under 10 by specifically making that sentence the highest probability in their model, and the user just had to hit space to enter it as the next word for each time. They rigged it for the test, they even admitted to it at the event. Of course they put it on their website too, because its a business and they could get away with it. Guiness really needs to start using new sentences for each competition.
Not that I know of, but it wouldn't really have been in my job category- that's something our PMs or buis-dev people would do, not really the developers. I'm not sure if we had any of theirs in our dictionary (the dictionaries were prepared by professional linguists, not by developers).
With a build that was pre-programmed to automatically text that message- they used that message to populate their n-gram models. We laughed about it at drinks with them after it. It was a big joke over how using the same message every time was a bad idea.
Try again. Swype (notice the spelling) has the world record for speed texting both normal and hands free (used by a handicapped man with a mouth controlled pointer).
Swiftkey only works well if you say the same thing a lot. If all of your texts are in the form of "what you doin" you'll do well with it (of course new versions of Swype have the same feature). If you're texting anything of substance, it does pretty poorly.
Feel free to show your friends though. Make sure they follow the links as well.
Forgot to mention this in the previous post- the research we saw showed that typing the full word was almost always quicker than tapping part of it and using prediction. Predictive ability was more useful for typo correction than it was for speed.
Seems like a waste to print those out- its a single number. I'd either just use my phone, or jot them down with pen and paper rather than pay to keep a printer in ink. Or not bother at all- I haven't had a airline, hotel, or theater ever not be able to look me up by name. If they can't find my name (uncommon name) in the system, most likely the entire order including id isn't in there.
I was lead Android dev at Swype, I'm quite sure I know alternative keyboards better than you. My limit is still about 20 words before I want a real keyboard. And I find actually using word prediction for future words is slower than tapping/swyping- it takes me longer to read the list, scroll through it, and tap an option than it would to just type the word, and it breaks up my flow.
Slashdot Mirror
Disagree. This would be MUCH clearer with better names. $file should be $filename. @file should be @fileLines or @fileData, to show that it holds the data from the file. %file should be something either naming the type of data used in it, or for a very generic function like that named to show that its the result of the operation. This would not pass a code review in any organization I've ever been part of.
No, perl arrays normally start from 0- unless you've overwritten perls $[ variable. Then they start from whatever you want.
Yes, that is fucking braindead. Its things like this that caused much of the perl hatred.
Yes, because nobody who writes in any other language indents for style reasons. Oh wait, EVERYONE does.
Meanwhile Python has actively cost me at least 2 weeks of time tracking down bugs that ended up being due to mixing of tabs and spaces causing incorrect nesting levels, but nobody could see it because it looked ok on the screen. No other language has ever caused me that.
Until Python loses that feature, its a complete non-starter to a lot of programmers. I despise perl, but I'd rather deal with line noise syntax and lack of an object model than python's whitespace issues.
Perl 6 has been just around the corner for 13 years. At this point do you really think it will ever actually be finished? If they were actually serious about it it would have come out a decade ago.
I don't find constant pair programming improves standards. I find it slows development to a crawl while leading to developers who are either mentally checked out or goofing around most of the day. Or depending on your developers, arguing over inanities. Or they just leave- I wouldn't stay at a job where I was going to literally have someone standing over my shoulder telling me what to do all day.
Code reviews are good, but you have the same problem as the OP does- you have to convince people not to half ass them. Its quite easy to fall into either rubber stamping (especially if you're busy), or arguing over trivial matters. Like any other tactic it takes people committed to quality and getting things done to make it work.
In the end, there's no substitute for developers who take pride in their work. You either have them or you don't. If you can't convince them to start taking it, no tool or technique will improve things.
Why the hell should a compiler know what JSON is? A compilers job is to turn code into machine or bytecode. Giving it more intelligence is a mistake. Generate the code maybe, but not as part of the compiler.
I'm going to disagree on easier to debug, because its impossible to step through the process of generation, which tends to be where the mistake is. It also means not all of your code is in source control, because the compiler itself becomes part of your code. I dislike the efficiency of runtime generation, but its more transparent because the generation code is part of your source.
No, that kind of stuff is WAY, WAY outside the scope of a compiler. Why the hell would a compiler even know JSON exists? You can argue its the job of a preprocessor or code generation utility run as part of your build process and you'd have a point. The advantage of using reflection is that all your code is in your source code and checked it- with preprocessing tools or code generation you're generating code at compile time which breaks a lot of tools and makes debugging errors much more difficult.
Its major use is to avoid busy work for the programmer. An example is ORM where the program can analyze what fields a class has and figure out what data types those fields are and build sql querries from it. Another example is xml/json parsing, where you can pass in a json string and a class definition and have it match all of the fields in the json to members in the class. You can spend 15 minutes writing annoying boilerplate code or 15 seconds making 1 method call.
Or someone who doesn't carry a backpack/purse/briefcase. If it doesn't fit in my pocket, it may as well be a desktop- I'm not taking it anywhere.
Wrong question. How many people love eating, don't want to be fat, and think that this could possibly be a good or healthy idea? And want to deal with the disposal and cleanup of the pumped material? I love eating and it would be great to lose 100 pounds, but I know that this isn't safe and is actually counter-productive.
It isn't even allowing me to register. Too bad- I have an app that automatically sends text messages to voice input/output mode when driving that would be MUCH nicer if it could interface with the car's speed detection than my rough estimates (for those interested, Text Soundly on the Google Play store). Not going to happen if I can't even download the SDK.
Yes we want pixel perfect rendering. Or rather, the web designers do. That's why HTML and CSS are the horrific combination they are today, and why web designers spend so much time tweaking things so they look exactly the same on all browsers. It's not what HTML and CSS were designed for, but it's how its used today. Time to move on and add a new language that uses it well.
Viewing source in the browser has some benefits. One of the major problems it has is that the browser then has to include an interpreter, forcing the developer to use the languages the browser knows. Which basically forces them to use only javascript. Moving to byte code would allow the program to be written in any language, a HUGE gain.
No, it is *VERY* concise. Specific words have an extremely specific meaning, and new concepts are defined in detail. That's why it reads the way it does. Writing it in plain english would take 5 or 6 times the amount of space to mean the same thing.
But conciseness isn't always the right goal. Take legalese- it's very concise. That's why its used. It isn't readable. Or take perl- people can do an awful lot in 1 line, but nobody can understand it without really studying it. Doing it in 5 or 6 lines instead can be much more readable, and thus maintainable.
Namespaces are pretty trivial to get around the lack of, C programmers have done it for 40 years and there's plenty of large systems written in it. It just takes discipline- prepend your function names with the module name. If you're in namespace window and have a function getHeight, you write it as window_getHeight. It takes a little bit of discipline, but not that much.
The real problem with web programming being unmaintainable is a combination of several factors, pretty much in this order:
1)Web programmers tend to be lower skill programmers. This is for historical reasons- when web apps didn't do much, good programmers wanted to work on more complex problems not just write a GUI for the hundredth time. It tends to be considered an entry level job, pays less,and lacks respect among programmers. Also, the lower barriers to entry on web programming means a lot of self-taught people enter that part of the field, who never really learn CS or software engineering.
2)There's a hack it and get it done mentality to web programmers. This comes from the quick cycle nature of web programming (which tends to be very visual based and small changes are easy to make on the fly) and the abundance of "agile" methodologies which tend to lack in design. Its made worse by how poor a markup language html/css are for what we try to make them do today and the amount of hacking that's necessary to get around browser incompatibilities.
3)The entire AJAX and framework of web programming is wrong. It was a quick hack added so that you could make dynamic apps using existing technologies without major changes to clients. But its layered hack upon hack upon hack. We really need to scrap it all and come up with a web application programming stack- a new markup language that's meant to do pixel perfect rendering (HTML is not, but its used that way), an HTTP replacement that's stateful rather than stateless, a cleaner way of sending data back and forth from the server. But if you write on top of an ugly platform, you're going to get ugly code.
4)Language issues. Javascript was never a good language- hell, you can tell that from the fact it's very name was a blatant marketing maneuver. Lack of a good object model is a real problem. Ideally you would want to be able to use any language here- maybe it's time to start delivering apps as byte code binary so the actual app can be written in whatever the programmer thinks best.
Unfortunately the last two of those would require fixes by the major browser vendors, the first two would take a decade of culture change to fix. So its going to continue to suck for a while.
The problem with a bluetooth keyboard is if I'm going to that trouble, why don't I just use a laptop? But yes, if you were going to try this for real a bluetooth keyboard is a must.
Swiftkey is an n-gram model where there's a probability of different words based on the previous words in the sentence. They got it to under 10 by specifically making that sentence the highest probability in their model, and the user just had to hit space to enter it as the next word for each time. They rigged it for the test, they even admitted to it at the event. Of course they put it on their website too, because its a business and they could get away with it. Guiness really needs to start using new sentences for each competition.
Hey man, haven't talked to you for years. You should send me an email, or a facebook request.
Not that I know of, but it wouldn't really have been in my job category- that's something our PMs or buis-dev people would do, not really the developers. I'm not sure if we had any of theirs in our dictionary (the dictionaries were prepared by professional linguists, not by developers).
With a build that was pre-programmed to automatically text that message- they used that message to populate their n-gram models. We laughed about it at drinks with them after it. It was a big joke over how using the same message every time was a bad idea.
Pop up lists? I killed the popup list myself 2 years ago- with release 3.0 on May 1st 2011. Try using anything recent?
Try again. Swype (notice the spelling) has the world record for speed texting both normal and hands free (used by a handicapped man with a mouth controlled pointer).
http://www.androidcentral.com/quadriplegic-sets-world-record-swype
http://techcrunch.com/2010/08/23/world-record-texting-speed-broken-and-once-again-its-with-swype/
Swiftkey only works well if you say the same thing a lot. If all of your texts are in the form of "what you doin" you'll do well with it (of course new versions of Swype have the same feature). If you're texting anything of substance, it does pretty poorly.
Feel free to show your friends though. Make sure they follow the links as well.
Forgot to mention this in the previous post- the research we saw showed that typing the full word was almost always quicker than tapping part of it and using prediction. Predictive ability was more useful for typo correction than it was for speed.
Seems like a waste to print those out- its a single number. I'd either just use my phone, or jot them down with pen and paper rather than pay to keep a printer in ink. Or not bother at all- I haven't had a airline, hotel, or theater ever not be able to look me up by name. If they can't find my name (uncommon name) in the system, most likely the entire order including id isn't in there.
I was lead Android dev at Swype, I'm quite sure I know alternative keyboards better than you. My limit is still about 20 words before I want a real keyboard. And I find actually using word prediction for future words is slower than tapping/swyping- it takes me longer to read the list, scroll through it, and tap an option than it would to just type the word, and it breaks up my flow.