The story might have been relevant to my interests in 2002. But it's clear now Linux is going to skip popularity on desktops and just do mobile instead.
Microsoft are going to make a tablet? About fucking time. I want to take notes on it with a stylus, not wave my fingers over the screen going 'oooo, I can make pictures big'. I want to be able stuff a USB stick in the side of it and put directories of data on it.
You have been able to a get a stylus-oriented Windows tablet computer with USB ports for ten years.
If it's like desktop anti-virus, it will have its own vulnerabilities, take up more resources than I'd like, cause buggy behaviour or incompatibilities with other apps, and feed me false positives too often.
I don't need that on my phone. Since the only real malware we've seen for the iphone involves jailbreaking and then not properly managing your phone, I can do without.
The article writer couldn't make up his mind if he was penning (1) an opinion piece, (2) a history of the deal, or (3) just trying to beat 19th century french novelists on wordiness.
I skimmed it, but all I got is: they wanted to put Yahoo into play. Is that it? Anyone have the abstract?
An RIAA lawyer today tipped poorly at the diner where he eats breakfast.
June Dawson, 43, waited on him this morning. She is a single mother of two, battling cancer. She was not enthusiastic about the tip: "He left a stinking dime. Next time I'm going to spit in his eggs."
The RIAA did not respond to enquiries at press time.
I have root on my workstation (cold dead hands and all), but not on a single server--not even a dev server.
sudo on things like mv and chmod gets you a root shell on the box fer chrissakes, why not just put the root password on a sticky on the rack?
When something goes wrong, I don't want to hear, "Maybe the dev did it." I didn't do it--no access. When we go to prod on something, I don't want to hear the admins complaining they don't know how to promote the app because some ass developer did it manually in dev instead of creating a proper install.
If you need root to chmod something, then your admin hasn't set up the box properly. Either he doesn't know what he's doing, or you haven't told him properly what sort of environment you need. Either get a better admin, or write up a clear description of all the functionality you require. Either way, you don't need root.
Of course, the smaller the business, the more likely an admin is a dev and vice versa. In that case, all bets are off.
Running debuggers in parallel - in the original language and in Java - is an invaluable way to follow through the logic and to check for inconsistencies and problems [in porting apps].
I don't envy you that work.:-)
I have been using interactive debugging for over 30 years, and it has been part of the best development systems ever written - Smalltalk IDEs.
I never did use smalltalk, but I have used its stepchild-with-pointers ObjC on NeXTStep. And ObjC is cute, so I imagine that Smalltalk was prettier.
I originally mistook your love for good tools for the modern Java-only code-monkey attitude. I swear, in two years, I'll be able to hire just the tools and leave the Java "programmers" unemployed.
BTW, (I'm thinking of your ports) isn't it amazing what programmers will go through because people can't come up with a new set of specs for they want the thing to do? I suppose it pays the bills.:-)
Sorry to come off brusque, as we seem to differ in quantity more than quality.
I simply can't imagine trying to debug a multi-threaded web application passing information between many levels of user interface, business logic and database interface simply using print statements and logs.
This is actually the work I do. I simply won't debug in such an environment. I will not step through the full code. Each interface between those levels should be well-defined, tested, and should log what it gets and what it returns upon request. The modules themselves should be small enough that stepping through is rarely needed. In my business (financial industry), we have to be able to tell what happened days/months/years after the fact; I cannot say "Hold on I'll attach a debugger to my prod webserver."
This is exactly where I have to train the kids away from debuggers, and get them to plan the interfaces and logging so that we can reconstruct the issue. Sure, attach a debugger in dev--who cares. But if you don't have a plan for well-tested modules connected by logged interfaces, then you lose money.
So I guess I see why you would want a debugger, but for me if you need one, then you're already in trouble.
The idea that you can develop multi-threaded applications of hundreds of thousands of lines of code simply using 'print statement' debugging and looking a code by eye is sheer wishful thinking.
Straw. You can just not develop something that's hundreds of thousands of lines of coupled nonsense. You modularize it and keep the code in smaller sections with clear interfaces which are graspable. Debugging should be a total last resort.
I'm not arguing against debugging environments, I'm arguing against relying on them to check your work. I wish I had a nickel for every bug some developer stuck into code I maintain on the idea that 'it can be debugged later' rather than validating it. Note that the first thing you said you needed in the language was a debugger: not a good standard library, not a flexible runtime engine, not a runtime shell like irb or clisp, not closures or good OO or fast reflection, but a debugger. I guess it just set me off.
I've worked on big programs that were easy to program (with low bug counts) because they were properly modularized. You could implement whole features just by checking out the sub-module (with only 5-10k lines) with the change, and running the tests in it. You could understand the code; the tests actually provided coverage enough to be confident.
I've also worked on big programs where a small change in some buried class would ripple through the codebase, providing a multi-hour "step-into" party to solve. And these coupled designs are almost impossible to add unit tests to, so you're stuck with the debugger for 70% of your work time.
I'm just advocating for the former over the latter. I find many "intermediate" programmers I work with don't realize there's an alternative to spending 6+ hours a day in a debugger.
The so-called 'IDE Crowd' have been leading the way in the way in software development techniques for over 30 years.
Trust me, I know. I've been maintaining this shit.
Seriously, though, half the problem with some of these new environments is over-complexity for a task (I'm looking at you, Java). The fact that you think you need an IDE and eg., multithreaded debugging to make the environment work show that you're in that over-complex world.
When you see an old-timer validate his code because it itself allows for inspection and dumping state, *and* has such a simple internal structure that you can understand the working parts, you realize that the IDE crowd missed something.
Someone that doesn't pay a dime for the content on the site but still complaints, even though he could as well have skipped the article in question. Check.
My eyeballs are counted in the numbers that OSDN uses to court advertiser dollars. I paid, whether I have a '*' next to my name or not.
And I bitch because I love.:-) Seriously, though, the slashvertisements that are interesting don't bother me. But this was poorly written, and boring as hell. A bar fridge with a sensor? Oh dear me, what will they think of next? Sheesh.
Ease-of-maitenance is one of the biggest worries with programming languages. Because of kludges like the above, it's easy to write hard-to-maintain Javascript code, therefore Javascript sucks.
Oh, hell, I've programmed Perl long enough to know that choice != hard to maintain. For your project, in your team, you pick a style standard and go with it. If your team isn't that adult, implement a lint to your liking or dust off your resume.
Slashdot Mirror
Isn't this Gnome, but ten years ago?
The story might have been relevant to my interests in 2002. But it's clear now Linux is going to skip popularity on desktops and just do mobile instead.
Not true.
http://en.wikipedia.org/wiki/Riparian_water_rights
Microsoft are going to make a tablet? About fucking time. I want to take notes on it with a stylus, not wave my fingers over the screen going 'oooo, I can make pictures big'. I want to be able stuff a USB stick in the side of it and put directories of data on it.
You have been able to a get a stylus-oriented Windows tablet computer with USB ports for ten years.
Bring on the rivals indeed.
If the book is half as impenetrable as the review, I don't think it's for me.
If it's like desktop anti-virus, it will have its own vulnerabilities, take up more resources than I'd like, cause buggy behaviour or incompatibilities with other apps, and feed me false positives too often.
I don't need that on my phone. Since the only real malware we've seen for the iphone involves jailbreaking and then not properly managing your phone, I can do without.
I love watermarks that can be defeated with a spellchecker and a thesaurus!
The article writer couldn't make up his mind if he was penning (1) an opinion piece, (2) a history of the deal, or (3) just trying to beat 19th century french novelists on wordiness.
I skimmed it, but all I got is: they wanted to put Yahoo into play. Is that it? Anyone have the abstract?
Yay, a Rickroll, that's so new and still funny.
An RIAA lawyer today tipped poorly at the diner where he eats breakfast.
June Dawson, 43, waited on him this morning. She is a single mother of two, battling cancer. She was not enthusiastic about the tip: "He left a stinking dime. Next time I'm going to spit in his eggs."
The RIAA did not respond to enquiries at press time.
If Linus posted a comment saying that ACLs were new and shiny, and in any case terribly superior to those he was copying, then yes.
It's not about whether or not MS is copying useful features. It's about not being a dick.
...and I do NOT WANT ROOT.
I have root on my workstation (cold dead hands and all), but not on a single server--not even a dev server.
sudo on things like mv and chmod gets you a root shell on the box fer chrissakes, why not just put the root password on a sticky on the rack?
When something goes wrong, I don't want to hear, "Maybe the dev did it." I didn't do it--no access. When we go to prod on something, I don't want to hear the admins complaining they don't know how to promote the app because some ass developer did it manually in dev instead of creating a proper install.
If you need root to chmod something, then your admin hasn't set up the box properly. Either he doesn't know what he's doing, or you haven't told him properly what sort of environment you need. Either get a better admin, or write up a clear description of all the functionality you require. Either way, you don't need root.
Of course, the smaller the business, the more likely an admin is a dev and vice versa. In that case, all bets are off.
I don't envy you that work. :-)
I never did use smalltalk, but I have used its stepchild-with-pointers ObjC on NeXTStep. And ObjC is cute, so I imagine that Smalltalk was prettier.
I originally mistook your love for good tools for the modern Java-only code-monkey attitude. I swear, in two years, I'll be able to hire just the tools and leave the Java "programmers" unemployed.
BTW, (I'm thinking of your ports) isn't it amazing what programmers will go through because people can't come up with a new set of specs for they want the thing to do? I suppose it pays the bills. :-)
Sorry to come off brusque, as we seem to differ in quantity more than quality.
This is actually the work I do. I simply won't debug in such an environment. I will not step through the full code. Each interface between those levels should be well-defined, tested, and should log what it gets and what it returns upon request. The modules themselves should be small enough that stepping through is rarely needed. In my business (financial industry), we have to be able to tell what happened days/months/years after the fact; I cannot say "Hold on I'll attach a debugger to my prod webserver."
This is exactly where I have to train the kids away from debuggers, and get them to plan the interfaces and logging so that we can reconstruct the issue. Sure, attach a debugger in dev--who cares. But if you don't have a plan for well-tested modules connected by logged interfaces, then you lose money.
So I guess I see why you would want a debugger, but for me if you need one, then you're already in trouble.
Straw. You can just not develop something that's hundreds of thousands of lines of coupled nonsense. You modularize it and keep the code in smaller sections with clear interfaces which are graspable. Debugging should be a total last resort.
I'm not arguing against debugging environments, I'm arguing against relying on them to check your work. I wish I had a nickel for every bug some developer stuck into code I maintain on the idea that 'it can be debugged later' rather than validating it. Note that the first thing you said you needed in the language was a debugger: not a good standard library, not a flexible runtime engine, not a runtime shell like irb or clisp, not closures or good OO or fast reflection, but a debugger. I guess it just set me off.
I've worked on big programs that were easy to program (with low bug counts) because they were properly modularized. You could implement whole features just by checking out the sub-module (with only 5-10k lines) with the change, and running the tests in it. You could understand the code; the tests actually provided coverage enough to be confident.
I've also worked on big programs where a small change in some buried class would ripple through the codebase, providing a multi-hour "step-into" party to solve. And these coupled designs are almost impossible to add unit tests to, so you're stuck with the debugger for 70% of your work time.
I'm just advocating for the former over the latter. I find many "intermediate" programmers I work with don't realize there's an alternative to spending 6+ hours a day in a debugger.
Trust me, I know. I've been maintaining this shit.
Ask, and ye shall receive.
Seriously, though, half the problem with some of these new environments is over-complexity for a task (I'm looking at you, Java). The fact that you think you need an IDE and eg., multithreaded debugging to make the environment work show that you're in that over-complex world.
When you see an old-timer validate his code because it itself allows for inspection and dumping state, *and* has such a simple internal structure that you can understand the working parts, you realize that the IDE crowd missed something.
Yes, but they have to wait for six months for an MRI like the rest of us socialist suckers.
My eyeballs are counted in the numbers that OSDN uses to court advertiser dollars. I paid, whether I have a '*' next to my name or not.
And I bitch because I love. :-) Seriously, though, the slashvertisements that are interesting don't bother me. But this was poorly written, and boring as hell. A bar fridge with a sensor? Oh dear me, what will they think of next? Sheesh.
Let's get our /. submission ready:
Now you too can pass yourself off as Roland Piquepaille!
I didn't know either, but he seems like an inventor of sorts.
clicky.
On a serious note, I can't wait to see either. I would hate to see this:
s/better/more restrictive/
Oh, hell, I've programmed Perl long enough to know that choice != hard to maintain. For your project, in your team, you pick a style standard and go with it. If your team isn't that adult, implement a lint to your liking or dust off your resume.
Thinking more about it, what you may want is an implementation of E4X, which looks cool. I think it's going into newer mozilla-based browsers soon.
It lets you address a parsed XML file in XPath-ish terms, like rootelement.child.text and such.