Comment Re:"Top Learning Language" ...OR... (Score 1) 415
Are those things relevant for all programmers any more?
Only the employed ones.
Are those things relevant for all programmers any more?
Only the employed ones.
Basically, if you are thinking your browser is a "platform", or you are thinking "the web" is "a platform" in the traditional programming sense, as the OP obvious is, then you are an idiot.
No, actually, he's quite right. It's a different method of programming, a different paradigm altogether. He didn't talk about programming the browser so that part of your statement is irrelevant, but as a design platform the web truly is different. At least before people tried to change a markup language into a full page layout and presentation language.
The problem with web applications - and the intrinsic problem of abstraction of the complexity that's solved by historical runtime environments that the OP likes, is that the render is independent. The whole article the other day about the Google device lab:
http://mobile.slashdot.org/sto...
Completely and totally underscores the fact that markup and rendering are separate from each other, and that the system doing the markup has to understand, and either have variant code that it outputs so that it renders the same in as many browsers as possible -- or you need an entire device lab, because you've given up on solving the problem, and are willing to employ someone other than a "Normal Human" (per the current article) in order to chip away on a per device basis, until you exhaustively cover all possibilities.
The separation on the render is the problem with the web, as a platform, and it's why it's * not* "a platform", it's "N back ends * M browsers" number of platforms.
This separation is the same mistake that was made when window management was separated from X windows, such that you didn't get the same look and feel on all applications based on having a particular X Terminal/X Server on which the render took place. In other words, the primitives were too primitive, and you ended up drawing boxes and lines and patterns, instead of "pop up menus" and "menu bards" and "dialog boxes".
What the OP in this article is bemoaning as being missing is a self-enforcing emergent property of the design decision to separate rendering from markup, and to separate markup from UI logic, and separate business logic from everything else. It's why web services are so complicated, and why they are so fragile.
The only thing that ever came close to dealing with the issue overall, at a high level, was WebObjects, and even then, it didn't try to do it in a way that was renderer/backend/middleware/security model/web server agnostic.
So again, I'm going to say that web services isn't a *platform* in the traditional sense of a computer running one of half a dozen 80x24 block mode terminals to front end a COBOL program was a platform, and that anyone who thinks it is
About as great a job as they are doing emulating a company that makes cell phones and tablets.
Let's not make a big deal out of this. 640kg of reactor-grade plutonium is only enough for a bit over 100 fission bombs / fusion bomb first stages, merely enough to make the recipient roughly tied for being the world's sixth most armed nuclear power.
Nothing to see here.
Clearly, you have never built a fission device, if you think you could get that many of them out of 640kg of even weapons grade Plutonium. You need to probably go back and read "The Curve of Binding Energy" and recalculate the neutron numbers to determine critical mass, assuming a pareto optimal design, because you are more than a bit high with "100"...
You could build a lot of dirty bombs with something like that, but you are likely better off just robbing a radiomedicine unit at a large research hospital to get the materials, or stealing a truck out of a fast food restaurant in Mexico City...
I call BS on EMACS...
...and Emacs traces its roots back to something like 1972.
You can't "And Constantly Swapping" unless it's running on a machine with virtual memory and swapping implemented.
You are right of course it is similar to the 80's and 90's in that companies that wanted to steal the sales of other companies simply created new fangled languages and marketed the hell out of them instead of embracing what works and adapting it to the new paradigms. The only reason you can't use Turbo Pascal to make web pages is the compiler was never updated for the functionality but it very well could have been. In fact its progeny Delphi is alive and well and building apps for almost every popular platform out there today including the web. As long as there is competition there will be someone who chooses to create from scratch rather than use someone else's tool.
The web is not a runtime environment.
The reason you can't use TurboPascal is because web pages run in the browser virtual machine, and TurboPascal code runs in the TurboPascal runtime environment linked into the native code TurboPascal application.
You could target TurboPascal to NACL/PiNACL in Chrome as a target runtime environment, but effectively to run it, you'd be doing a JavaScript call into a JavaScript extension that then ran as native code in a sandbox within Chome. You'd, as a result, lose most of the TurboPascal runtime libraries supplied by the compiler vendor, and you'd lose all third party libraries and components, if the third parties weren't willing to port them (I assume you realize that you don't have all the Photoshop plugins on Windows that are available on Mac, right?).
Web languages, n the other hand, are predominantly for programming code on a server to generate markup, which is then interpreted by the browser to render output, or they are intended to run in a really limited environment in the browser itself, usually as unextended JavaScript (and, in the case of things like iPad/iPhone/etc., they are *definitely* NOT extended, since a UIView extension is not allowed under the terms and conditions for interpreting web content, since it's a huge security hole that's easily exploited with a DNS hijack).
Basically, if you are thinking your browser is a "platform", or you are thinking "the web" is "a platform" in the traditional programming sense, as the OP obvious is, then you are an idiot.
Better add DARPA and Jon Postel as codefendants. I hear they came up with this thing called TCP/IP, which aids and abets people like Tor putting together anonymous networks in the first place; it's a clear case of collusion...
Bonus Points: I hear DARPA has deep pockets...
What exactly is the point of spending so much money on hardware when you could run >40 virtual machines emulating different Android devices?
Most companies producing devices with browsers are pretty ass about providing working simulators/emulators for the hardware.
This is OK for one company, like Google or Roxio, to deal with supporting a lot of platforms with all sorts of physical differences from there being no hardware standard for Android devices to which vendors have to adhere, but
"Welcome to the Blackberry video rental site!
"Top Learning Language"
Do we have some great metrics as to how well people taught in Python actually *learn*? You know, for things like memory allocation, pointers, and so on?
FWIW, Washtech is a CWA union local...
It's possible that they have the best interests of IT people in their hearts, but it's more likely that they, like the Alliance@IBM guys, also a CWA union local, have a bit of an axe to grind against IBM.
The other two seem more or less non-affiliated, so they perhaps do not have an axe to grind against IBM. It'd bee interesting to know which group(s) picked which target(s) in this story.
Also, FWIW, the CWA is a pretty piss poor match for programmers and other IT folks, but since automation of telephone operators jobs, they've been branching out to "anyone who uses a communications network, no matter how automated and non-labor intensive" as potential members. It's not a great fit, so they've had pretty much zero success in the IBM shops they've picketed (including one I worked for at one time).
H1-Bs in America currently have two options: 1) Remain at current sponsoring employer or 2) go home, because quitting means immediate revocation of their visa.
2B: Hop to an employer that is willing to sponsor a change in their H1-B.
From Wikipedia:
Despite a limit on length of stay, no requirement exists that the individual remain for any period in the job the visa was originally issued for. This is known as H-1B portability or transfer, provided the new employer sponsors another H-1B visa
From the employees perspective, there is one problem with this: once an employer has started the permanent residency (greencard) process, it is a bad idea to move because you'll be starting all over again.
A take-over is easier than a reapplication for a new visa, if the current visa limit is exhausted (which it constantly is), so unless this happens at the start of a year, and you have all the ducks in a row before tendering notice, you are likely going home as soon as you give notice to the current visa sponsor.
A take-over is allowed, but voluntary on the part of the original sponsor, who may be, er, a "little spiteful"...
The law was changed over 15 years ago to allow the same H1B to be used when changing jobs.
You can transfer an H1-B, but the employer who currently holds it has to approve the transfer. The employer holding it can refuse to perform a transfer, and prevent the operation.
The law you refer to assumes cooperation between the parties.
It's occasionally found for some companies to basically hold "H1-B" and "Green Card Application" hostages to work at lower wages. I've worked at a couple of companies which I later found out employed this tactic, and I've seen several contracting agencies that contract for work, H1-B in workers, and then take up to 70% "commission" on the contract wages on top of everything else.
The most intriguing thing in this to me...
I still miss it. Surely the data harvesting would have been worth it, for a behemoth like Google to just keep it running.
I use Feedly, but it's not the same.
The problem was the API let people write clients that removed the value to Google of running the service (i.e. the advertisements).
Google was willing to give the code over to any third party who wanted to commit to supporting it, and even host it on Google's infrastructure, if they were paid to do so, but there wasn't any way to monetize it, given the API split and the ad stripping by the clients of the API. Apparently stream bookmarking and privacy weren't worth sitting through the ads to anyone, as no one was able to come up with a viable business model that kept the good stuff, but was still able to be monetized enough to at least break even.
But hey, I'll happily join you to complain about stuff I no longer get free, too, if that will make you feel better, like those game cards you could get at Chick-fil-a in the mall, go down to the Walden Books, look up the answers in the almanac, and then go back to Chick-fil-a for the free food item because you got the right answer, and get the next game card.
Always draw your curves, then plot your reading.
