Want a scare? Do an "emerge -e world" on Gentoo, and run a script on the output to count how many "result unused on function declared with 'warn on unused result'" messages you see.
If your code is to be maintained by junior programmers, then choose a managed code environment.
With that one criterion, you may have completely struck those languages from candidacy for any project whatsoever.
All C and C++ programmers are "junior programmers" while they become proficient with the language, and nobody becomes a "senior programmer" without having learned from their own mistakes. You can't jump to C (or even C++) from languages like Python or PHP without undergoing a set of major paradigm shifts, and I'm not just talking about memory management.
I coded for AWT and Swing in the 90s. The app you use to demonstrate looks a lot nicer than anything I recall seing use those toolkits back then.
Also, honestly, the app you link too looks like it has a reasonable UI for the role it performs. I would love to see current apps that work well for power users*, but which have "sleek" UIs. 90% of "good UI design" is moving 90% of advanced features and behaviors away from the first impression.
* read: "People who don't stop learning how to do the thing better"
Yeah? Well bow in respect to mine. I wrote TFA in question, and I didn't write any of the ones you cite. Neither were they submitted by me or anyone I know. Does my editorial recap known facts? Sure, but that's how one explains things. If you know every point contained in my editorial -- assuming you made it to the end -- consider yourself clever. Perhaps you weren't the intended audience.
Yipes! *bows hurriedly*
Ok, I made the mistake of assuming the submitter was the same as the author, because the submitter's name links to Infoworld. I've seen author-submitted posts on Slashdot's front page so many times, it's almost expected. My apologies.
Having gone through and read the article line-by-line (I don't usually read IW articles, because, well, I prefer more-technical articles than I've seen them write.) The rest of my brief analysis was based on a very poorly-written/. submission; the submission speaks of Oracle's desires to act against open-source Java and the Apache foundation, whereas the article doesn't even address that prospect.
So, yes, my comment was wrong. I'm sorry. I'll buy you a beer if you're ever in my area. (And I know where the good microbrews are around here, too)
Just one question: when was the last time when you wrote code using XLib? Or XCB for that matter.
A few months ago. Why? Personal interest. More recently, I've been working on tracking down a bug I've noticed when running luminance-hdr over X11 forwarding over SSH. I get X11 protocol errors which suggest data corruption. I think the bug is in either my sshd or my ssh client; I don't get the errors if I run over raw TCP.
It's very hard to do stuff with the old ways of X. It's very hard to get over the damned protocol to actually have some fast graphics.
I don't disagree. If you have an app which requires a high framerate with active changes in graphics, raw X11 isn't going to be close to ideal, and it doesn't seem that the existing commonly-available extensions to X make it much easier.
The X protocol is bad, and it's bad not because the design is bad (some ideas are very neat, really) but because the evolution of hardware and software made it obsolete.
Here I'd disagree with the wording, but you're substantially correct. The path of hardware and software evolution have made it inconvenient. It was driven by demand for fast, cheap 3D rendering on consumer PCs on Windows. (Which is probably part of why I keep hearing Wayland compared to Windows' graphical model)
This drove an assumption of very-low-latency connections between the graphical display and the application, and that assumption persists to this day.
But the 'old anonymous coward fart' wants to use his xfig, he's more than welcome. He can use it in a virtual machine, where he runs his old distribution, hopefully with better performances because Wayland helps instead of getting in the way.
I'm not the AC you're referring to, but I'm also one who loves X11. I've got two beefy machines on my network at home--mine and my fiancee's. When we have roleplaying company over, we both regularly use X11-over-SSH to run programs like PCGen or GURPS Character Assistant on laptops in a different room. When we're doing photo processing, we both regularly use X11 over the network to run our photo processing apps (she prefers ufraw, while I go for luminance-hdr).
I don't see how Wayland will help in that scenario.
And BTW: I wonder how many FTP servers implement that feature you're talking about.
Any that support both active and passive FTP modes, implemented naively (some FTP servers explicitly block active transfers to any but the user's IP as a security mechanism). This use case is specifically spelled out in RFC 959. See figure 2 in section 2.3. You, the user, open a control connection to both servers, you tell server1 to transfer the file passively (wait for a connection on a port), and you tell server2 to transfer the file actively, specifying server1:port as the destination.
I'm familiar with RDP; that's the protocol Windows Terminal Services has used for years. I hadn't heard about SPICE, though.SPICE looks nice, but which version (or which extensions) of RDP is to be used?
Furthermore, my day job has had me spend many hours writing high-performance C++ code for Win32. RDP is a PITA. For applications which are already running, it pulls tricks like changing the display depth on-the-fly. We had to fall back to using GDI+ (which is slow, but hardware thankfully caught up) to maintain general compatibility.
P.S. I would love to have some guarantees that X would survive and I would be able to run a GUI app remotely, but something tells me that the days when I was taking that for granted are counted.
When I first heard about Wayland, I dropped into their IRC channel to ask if they were at least going to support network transparency. I was told that it was a low priority. Which tells me that it's not even going to highly considered in their API designs.
I expect it to act like VNC, at best. Which is going to royally suck.
Last time I checked, nobody was forcing you to switch from X to Wayland or Gnome 2 to 3.
And nobody forced me to switch from GNOME 1.4 to GNOME 2, right? Or from browsers that support HTML 1 to HTML 5? Or from FTP+{IPSec|SSL} to SFTP?Wherever the most users are, that's where developers will go. Developer time is a finite resource, and any time developers go somewhere, they have to leave something behind.
I'm not saying that we shouldn't move to new systems, but there are very stable and usable features in old systems which don't exist in new systems, and there's always some cost..
Some apps written for GNOME 1.4 were never ported to GNOME 2, because their developers abandoned them. (I can't think of examples off-hand, I just recall encountering the problem at the time of transition) HTML 1 was a very simple, straightforward means of conveying information for rendering and presenting to humans. It just wasn't fancy enough, so it was replaced. Did you know that FTP allows you to instruct one FTP server to transfer a file to another? That's pretty epic when the two servers have a connection 10-100 times as fast as your connection to either--and tools like IPSec, SSL or a secured layer 2 made that reasonably safe.
Yes, each of these older systems had their own faults, and newer versions sought to cope with those faults, but new versions often fail to retain the flexibility and existing utility of old versions. I shudder to think how many hours of coder's times are spent shoehorning existing things into new systems or on top of new paradigms. Worse, everybody thinks they've invented something new, when all they've done is (often inadvertently) re-invented something a decade or six old in a new context.
It feels like make-work for a stagnant field. Pay someone to tear down the old road and build a new road, except the new road isn't even expected to last as long. We're not accelerating innovation as fast as we tend to think, we're stuck in a mud puddle and spinning our wheels.
This isn't a news article. This is an article about two previous news articles. There's nothing to see coming. Submitted by the author of an article about the two previous stories. Slow news day, I hope; this is just a group-think trajectory thing.
Does this we can't get above a certain percentage of correct predictions, or does it mean that more and more work will converge towards 100% (99.5, 99.9%, 99.999% etc. etc.)
Different solution. This isn't a watchdog, this is a, "hey, this program's been here before. And once it's been here, it'll go there. And then there. And then here. And it won't stop."
Any recursive function can be converted to a loop, and vice versa. Of course, any real machine will have a finite heap, so you wouldn't be able to properly emulate a machine with an infinite stack. (Which would be the analogous counterpart to your implied infinite heap, if we include the constraints in a transformation)
My day job has me writing custom C++ code for Windows. We only just recently were able to drop support for Win2K. As in, within the past year. I'm immensely looking forward to XP going the way of the dodo; our software is ready for Vista and Win7 already, but there are kernel features we can't touch as long as we need to be able to run on WinXP. Things like functioning reader/writer locks which integrate well with the rest of system APIs--we had to roll our own, and they won't integrate with the rest of the system*. In other news, correctly implementing such things is non-trivial.
* No way in hell Microsoft will let third-party code run inside the critical sections for managing resources in things like WaitForSingleObject--and I wouldn't want them to.
Does a headline that ends in a question mark set off your red flags? Can I convince you to buy this bridge I'm selling by hinting at it using a question? What if I cobble together a tiny tidbit of info from groklaw with a really inflammatory headline, will slashdot publish it?
You seem to be advocating a distinction of responsibility of knowledge where programmers should not need knowledge of design. I would dispute that.
First, all you've done is replace "programmer" with "compiler." If you posit that there is no need for programmers to do anything more than convert a design specification to code, then all you've done is define programmers as transcoders operating on a higher-level formal langauge than current compilers already do. That seems ridiculous; you'd be able to replace "programmers" with "compilers" for this higher-level language ("Technical writing in English") your design spec is written in. At that point, your designers are doing nothing more than programming in a higher-level language...making them programmers again. Look at the trends in new and redeveloped languages to include declarative behaviors for evidence of this already happening; dataflow-driven and declaration-driven language features are getting a lot of attention.
Second, if your programmers aren't expected to have or build knowledge of good design and design practices, then they won't be able to identify mistakes--especially critical mistakes such as the ones discussed in TFA. People are people, people make mistakes. Without other people or tools (created by people) there to catch some the mistakes, more of the mistakes slip past. And while it's perhaps easy to build a unit test suite from a design document, that unit test suite is going to be better at detecting flaws in the code, not in the design.
There's a difference between 'make' and 'design'; that's why they have supercomputers for 'testing' in massive physics simulations. Care to provide specific, relevant not-out-of-context quotes from the PDFs in the list you linked to?
My best guess is that some people I have as contacts on FB are more prone than yours to trying dozens of new apps each week, and so I'm at a greater risk.
I've gotten the same reaction from other people, and it wasn't until they were standing behind me when it happened that they believed me. When the same kind of things happens once in a while across three browsers over two different operating systems across five or six different machines over three or four ISPs, I'm pretty sure it's not a local virus or bit of malware.
"I've never seen it, ergo it's irrelevent" is one of the silliest and most pointless recurring arguments I hear.
All of the features touted in this language are things that either already exist, or for any well designed application be a non-issue.
There's more to language design than creating new features. Most languages I've seen introduce few, if any, new or fundamental features, but instead seek different balances in the various tradeoffs involved. Off the top of my head, those tradeoffs include things like raw speed, syntax expressiveness, syntax flexibility, memory consumption, number, breadth and convenience of builtins and number, breadth and convenience of libraries.
Most languages even seek to remove some mundane aspects of architecting a "well-designed application;" it's been a long, long time since most programmers had to manually keep track of their memory consumption or object interaction models for trivial applications, but applications which we would consider trivial today would have required extraordinary amount of programmer effort thirty years ago for such things. Non-issues in a well-designed application eventually become non-issues in any trivial application; even the painstakingly-well-designed application itself may eventually become trivial.
"Advanced primitives" isn't an oxymoron if you evaluate it in the right context; you're missing the implicit "when compared to {other language's primitives}". Granted, it's still a vague term; compared to what? Compared to C primitives? Possibly. Compared to Java primitives? Possibly.
Oz's syntax doesn't look any stranger to me than comparing a C-like syntax with a FORTAN-like syntax, or either of those with a Lisp-like syntax.
If you want a bizarre syntax, see J. Before you knock it, consider its heritage, and figure out which you'd have an easier time entering on your average keyboard.
No, I don't know Oz. I don't know Scala. I don't know Ozma. I just watch a lot of language advocates and designers compete with each other, and learn a thing or two every now and then--and it irritates me when I see people knock langauges and tools because they don't have enough perspective to see that those tools might not be right for them, but might be right for someone else.
Slashdot Mirror
Want a scare? Do an "emerge -e world" on Gentoo, and run a script on the output to count how many "result unused on function declared with 'warn on unused result'" messages you see.
(Disclaimer: C++ is my second-favorite language. I want it to be liked and used, but I'm realistic.)
I'm curious. What's your favorite?
If your code is to be maintained by junior programmers, then choose a managed code environment.
With that one criterion, you may have completely struck those languages from candidacy for any project whatsoever.
All C and C++ programmers are "junior programmers" while they become proficient with the language, and nobody becomes a "senior programmer" without having learned from their own mistakes. You can't jump to C (or even C++) from languages like Python or PHP without undergoing a set of major paradigm shifts, and I'm not just talking about memory management.
One does not "simply walk into C++."
I coded for AWT and Swing in the 90s. The app you use to demonstrate looks a lot nicer than anything I recall seing use those toolkits back then.
Also, honestly, the app you link too looks like it has a reasonable UI for the role it performs. I would love to see current apps that work well for power users*, but which have "sleek" UIs. 90% of "good UI design" is moving 90% of advanced features and behaviors away from the first impression.
* read: "People who don't stop learning how to do the thing better"
Yeah? Well bow in respect to mine. I wrote TFA in question, and I didn't write any of the ones you cite. Neither were they submitted by me or anyone I know. Does my editorial recap known facts? Sure, but that's how one explains things. If you know every point contained in my editorial -- assuming you made it to the end -- consider yourself clever. Perhaps you weren't the intended audience.
Yipes! *bows hurriedly*
Ok, I made the mistake of assuming the submitter was the same as the author, because the submitter's name links to Infoworld. I've seen author-submitted posts on Slashdot's front page so many times, it's almost expected. My apologies.
Having gone through and read the article line-by-line (I don't usually read IW articles, because, well, I prefer more-technical articles than I've seen them write.) The rest of my brief analysis was based on a very poorly-written /. submission; the submission speaks of Oracle's desires to act against open-source Java and the Apache foundation, whereas the article doesn't even address that prospect.
So, yes, my comment was wrong. I'm sorry. I'll buy you a beer if you're ever in my area. (And I know where the good microbrews are around here, too)
Do you mean resolution can change on the fly? What ever shall we do?
</snark>
No, I'm talking about display depth. Resolution changing on the fly wouldn't have been a problem.
Just one question: when was the last time when you wrote code using XLib? Or XCB for that matter.
A few months ago. Why? Personal interest. More recently, I've been working on tracking down a bug I've noticed when running luminance-hdr over X11 forwarding over SSH. I get X11 protocol errors which suggest data corruption. I think the bug is in either my sshd or my ssh client; I don't get the errors if I run over raw TCP.
It's very hard to do stuff with the old ways of X. It's very hard to get over the damned protocol to actually have some fast graphics.
I don't disagree. If you have an app which requires a high framerate with active changes in graphics, raw X11 isn't going to be close to ideal, and it doesn't seem that the existing commonly-available extensions to X make it much easier.
The X protocol is bad, and it's bad not because the design is bad (some ideas are very neat, really) but because the evolution of hardware and software made it obsolete.
Here I'd disagree with the wording, but you're substantially correct. The path of hardware and software evolution have made it inconvenient. It was driven by demand for fast, cheap 3D rendering on consumer PCs on Windows. (Which is probably part of why I keep hearing Wayland compared to Windows' graphical model)
This drove an assumption of very-low-latency connections between the graphical display and the application, and that assumption persists to this day.
But the 'old anonymous coward fart' wants to use his xfig, he's more than welcome. He can use it in a virtual machine, where he runs his old distribution, hopefully with better performances because Wayland helps instead of getting in the way.
I'm not the AC you're referring to, but I'm also one who loves X11. I've got two beefy machines on my network at home--mine and my fiancee's. When we have roleplaying company over, we both regularly use X11-over-SSH to run programs like PCGen or GURPS Character Assistant on laptops in a different room. When we're doing photo processing, we both regularly use X11 over the network to run our photo processing apps (she prefers ufraw, while I go for luminance-hdr).
I don't see how Wayland will help in that scenario.
And BTW: I wonder how many FTP servers implement that feature you're talking about.
Any that support both active and passive FTP modes, implemented naively (some FTP servers explicitly block active transfers to any but the user's IP as a security mechanism). This use case is specifically spelled out in RFC 959. See figure 2 in section 2.3. You, the user, open a control connection to both servers, you tell server1 to transfer the file passively (wait for a connection on a port), and you tell server2 to transfer the file actively, specifying server1:port as the destination.
I'm familiar with RDP; that's the protocol Windows Terminal Services has used for years. I hadn't heard about SPICE, though.SPICE looks nice, but which version (or which extensions) of RDP is to be used?
Furthermore, my day job has had me spend many hours writing high-performance C++ code for Win32. RDP is a PITA. For applications which are already running, it pulls tricks like changing the display depth on-the-fly. We had to fall back to using GDI+ (which is slow, but hardware thankfully caught up) to maintain general compatibility.
P.S. I would love to have some guarantees that X would survive and I would be able to run a GUI app remotely, but something tells me that the days when I was taking that for granted are counted.
When I first heard about Wayland, I dropped into their IRC channel to ask if they were at least going to support network transparency. I was told that it was a low priority. Which tells me that it's not even going to highly considered in their API designs.
I expect it to act like VNC, at best. Which is going to royally suck.
Last time I checked, nobody was forcing you to switch from X to Wayland or Gnome 2 to 3.
And nobody forced me to switch from GNOME 1.4 to GNOME 2, right? Or from browsers that support HTML 1 to HTML 5? Or from FTP+{IPSec|SSL} to SFTP?Wherever the most users are, that's where developers will go. Developer time is a finite resource, and any time developers go somewhere, they have to leave something behind.
I'm not saying that we shouldn't move to new systems, but there are very stable and usable features in old systems which don't exist in new systems, and there's always some cost..
Some apps written for GNOME 1.4 were never ported to GNOME 2, because their developers abandoned them. (I can't think of examples off-hand, I just recall encountering the problem at the time of transition) HTML 1 was a very simple, straightforward means of conveying information for rendering and presenting to humans. It just wasn't fancy enough, so it was replaced. Did you know that FTP allows you to instruct one FTP server to transfer a file to another? That's pretty epic when the two servers have a connection 10-100 times as fast as your connection to either--and tools like IPSec, SSL or a secured layer 2 made that reasonably safe.
Yes, each of these older systems had their own faults, and newer versions sought to cope with those faults, but new versions often fail to retain the flexibility and existing utility of old versions. I shudder to think how many hours of coder's times are spent shoehorning existing things into new systems or on top of new paradigms. Worse, everybody thinks they've invented something new, when all they've done is (often inadvertently) re-invented something a decade or six old in a new context.
It feels like make-work for a stagnant field. Pay someone to tear down the old road and build a new road, except the new road isn't even expected to last as long. We're not accelerating innovation as fast as we tend to think, we're stuck in a mud puddle and spinning our wheels.
usually, wired ones bow down to short circuits...
Are you suggesting he salutes his shorts?
I bow in respect to the lower UID.
Really, who didn't see this coming?
This isn't a news article. This is an article about two previous news articles. There's nothing to see coming. Submitted by the author of an article about the two previous stories. Slow news day, I hope; this is just a group-think trajectory thing.
Does this we can't get above a certain percentage of correct predictions, or does it mean that more and more work will converge towards 100% (99.5, 99.9%, 99.999% etc. etc.)
It means one of those two things is true, yes.
Different solution. This isn't a watchdog, this is a, "hey, this program's been here before. And once it's been here, it'll go there. And then there. And then here. And it won't stop."
One bright side: The song that never ends...will.
In my own code, even.
Any recursive function can be converted to a loop, and vice versa. Of course, any real machine will have a finite heap, so you wouldn't be able to properly emulate a machine with an infinite stack. (Which would be the analogous counterpart to your implied infinite heap, if we include the constraints in a transformation)
My day job has me writing custom C++ code for Windows. We only just recently were able to drop support for Win2K. As in, within the past year. I'm immensely looking forward to XP going the way of the dodo; our software is ready for Vista and Win7 already, but there are kernel features we can't touch as long as we need to be able to run on WinXP. Things like functioning reader/writer locks which integrate well with the rest of system APIs--we had to roll our own, and they won't integrate with the rest of the system*. In other news, correctly implementing such things is non-trivial.
* No way in hell Microsoft will let third-party code run inside the critical sections for managing resources in things like WaitForSingleObject--and I wouldn't want them to.
You decide!
You seem to be advocating a distinction of responsibility of knowledge where programmers should not need knowledge of design. I would dispute that.
First, all you've done is replace "programmer" with "compiler." If you posit that there is no need for programmers to do anything more than convert a design specification to code, then all you've done is define programmers as transcoders operating on a higher-level formal langauge than current compilers already do. That seems ridiculous; you'd be able to replace "programmers" with "compilers" for this higher-level language ("Technical writing in English") your design spec is written in. At that point, your designers are doing nothing more than programming in a higher-level language...making them programmers again. Look at the trends in new and redeveloped languages to include declarative behaviors for evidence of this already happening; dataflow-driven and declaration-driven language features are getting a lot of attention.
Second, if your programmers aren't expected to have or build knowledge of good design and design practices, then they won't be able to identify mistakes--especially critical mistakes such as the ones discussed in TFA. People are people, people make mistakes. Without other people or tools (created by people) there to catch some the mistakes, more of the mistakes slip past. And while it's perhaps easy to build a unit test suite from a design document, that unit test suite is going to be better at detecting flaws in the code, not in the design.
There's a difference between 'make' and 'design'; that's why they have supercomputers for 'testing' in massive physics simulations. Care to provide specific, relevant not-out-of-context quotes from the PDFs in the list you linked to?
My best guess is that some people I have as contacts on FB are more prone than yours to trying dozens of new apps each week, and so I'm at a greater risk.
I've gotten the same reaction from other people, and it wasn't until they were standing behind me when it happened that they believed me. When the same kind of things happens once in a while across three browsers over two different operating systems across five or six different machines over three or four ISPs, I'm pretty sure it's not a local virus or bit of malware.
"I've never seen it, ergo it's irrelevent" is one of the silliest and most pointless recurring arguments I hear.
FWIW, the same problem exists with Flickr.
However, nothing prevented me from getting my own API key to feed a flickr/FUSE app as a command-line parameter.
All of the features touted in this language are things that either already exist, or for any well designed application be a non-issue.
There's more to language design than creating new features. Most languages I've seen introduce few, if any, new or fundamental features, but instead seek different balances in the various tradeoffs involved. Off the top of my head, those tradeoffs include things like raw speed, syntax expressiveness, syntax flexibility, memory consumption, number, breadth and convenience of builtins and number, breadth and convenience of libraries.
Most languages even seek to remove some mundane aspects of architecting a "well-designed application;" it's been a long, long time since most programmers had to manually keep track of their memory consumption or object interaction models for trivial applications, but applications which we would consider trivial today would have required extraordinary amount of programmer effort thirty years ago for such things. Non-issues in a well-designed application eventually become non-issues in any trivial application; even the painstakingly-well-designed application itself may eventually become trivial.
"Advanced primitives" isn't an oxymoron if you evaluate it in the right context; you're missing the implicit "when compared to {other language's primitives}". Granted, it's still a vague term; compared to what? Compared to C primitives? Possibly. Compared to Java primitives? Possibly.
Oz's syntax doesn't look any stranger to me than comparing a C-like syntax with a FORTAN-like syntax, or either of those with a Lisp-like syntax.
If you want a bizarre syntax, see J. Before you knock it, consider its heritage, and figure out which you'd have an easier time entering on your average keyboard.
No, I don't know Oz. I don't know Scala. I don't know Ozma. I just watch a lot of language advocates and designers compete with each other, and learn a thing or two every now and then--and it irritates me when I see people knock langauges and tools because they don't have enough perspective to see that those tools might not be right for them, but might be right for someone else.
In programming, "paradigm" usually refers to a mindset or a "way of doing things." You might find this useful.