BASIC is every bit as modern as any other language and structurally equivalent to any modern static language. It's more verbose than C and similar languages [...]
Verbosity is the problem.
If I were fine with the screens and screens of the boilerplate code, I would have simply used the Java.
I don't understand why you couldn't get QtCreator working. Qt is easy to install and use on Ubuntu. And the Qt QUI designer is very easy to work with.
As I heard it was a systemic problem back then: not all package dependencies were declared, meaning that after installation you have to also install bunch of other stuff to make it working. (Many years ago, first time I tried QtCreator, it actually refused to run, because some linked libraries were missing.)
I'm not sure about now, but back then it wasn't even close to anything RAD. It was only a helper to create the GUI in a XML form, which was back then not even properly integrated with the rest: one had to write some code manually to actually tell Qt what resource corresponds to the window. And add resource manually to the resource file.
I would say that Python + libglade + glade is also a pretty good combination. It's not quite the RAD experience you seem to want, but it is a fast and powerful way of developing GUI apps, thanks go a nice API and Python.
Yes, it is not RAD. And for that I already use QT + C++, which provides very powerful, simple and no-fuss API to build GUIs dynamically (without external UI building tools like glade or Qt Designer).
The problem is not me per se - I have no problems with most of the stuff. The problem are the other team-members who are not well versed as me in the scripting languages and building GUIs. On many past projects I have left behind lots of stuff which 95% of coworkers can't support or develop further. And I want to solve the problem by throwing in something that requires as least boilerplate as possible, stays as close to demos/examples as possible. I'm simply trying to find something to help the people start moving in the right direction.
Xubuntu 14.04 says that the installation would take 195MB of space. Bit heavy. Worst part: it is BASIC.
On the positive side, Lazarus + FP SDK, requires almost 1GB of space on my Xubuntu.
My ultimate goal is to be able to put together a quick UI, check in the source, and tell in few words to others who going to check it out how to compile it and get it running.
All in all, Xojo gets on the short list of things to try.
Only after I have pressed "Post" button, I hare realized that I probably given not enough context.
"Anything unique to a Linux developer who looks for RAD on Linux"?
From RAD for Linux, I'm aware only of the FreePascal-based Lazarus (Borland Delphi remake).
Past attempts with the KDevelop (and QtCreator) were pretty abysmal: right after "apt-get install" and few clicks to throw together UI, they were failing simply to compile the "Hello World" msgbox application. (And wild goose chase to install what was missing was counter the whole idea of *rapid* application development.)
That became patently obvious to me when I have tried to buy a "generic" ARM board (Raspberry, Banana, Odroid) for Ubuntu.
It just doesn't exist.
There is no IMB/Intel/Microsoft aliance to help create and maintain a standard ARM-based platform. And it seems all vendors try to differentiate, making the devices slightly incompatible with each other.
The most ridiculous part is that past boot loader/after kernel is loaded, differences are minimal and can be expressed with the Linux' device tree. But it is apparent that nobody makes an effort even to catalog the differences. Google, with their rolling releases and "selected" devices, is simply oblivious to the rest of the market.
Which is closer to desktop Linux: Firefox OS, Sailfish, Ubuntu Touch, Cyanogenmod, OxygenOS, Tizen?
None. Or rather: Linux desktop with systemd and Wayland is headed the way of mobile phones.
Flashing ROM, if possible at all, is a nice thing to avoid. Any suggestions?
At least in the past, Samsung devices were recommended. They keep backup copy of the original OS on the flash, I was told. If you flash alternative OS and something goes wrong, you can still boot the original OS and repair/reinstall. (One of the reasons why CyanogenMod was originally developed on Samsung devices.) But I haven't tried that personally.
Long time ago I have read about. The crater was known about for many years now. But for it to be registered officially as an impact crater, they had to find the impact center and let other scientists review the work. When I read about it, they found the suspected impact center and were preparing for drilling. From the TFA, it seems that they have finally dug up the evidence, but I see no mention of it being officially confirmed.
Crater wasn't found. They have just dug up and analyzed the first samples. No mention of it being "confirmed". Though Wikipedia still lists it as unconfirmed.
The problem is that every time you open a slashdot page, 1.1MB of (minified) JS code has to be parsed by the browser. Every damn Time.
No managed language (especially of the "everything is an object" garbage collected ones) are capable of parsing that in a reasonable time below 1s.
In dial-up times everything was slow because the "last mile" was slow. These days it is slow, because "web designers" effectively became a synonym to "mentally retarded hipsters".
Look at the slashdot. It would take probably 50-100 lines of PHP (or Perl/CGI) to create the main page and comments page(*) each, which would (A) take fraction of RAM/CPU resources and (B) load effectively at the speed the DB needs to fetch the data from disk (if they are not cached) (because disk is the slowest link in all that). Another smallish CGI for the login/logout. Throw in 50-100 lines of the CSS for the visual style. And probably 50 or so lines of the JS for the comment form. And another CGI for posting the comment in DB. And that's about 99% of the Slashdot I ever use. Now compare with the unmanageable clusterfuck we have. Or worse: compare to the beta.
(*) The tree organization of the comment might take bit more code.
I see where you coming from and actually I do not disagree with you.
Basically we just have different priorities.
Firefox has been hanging more for us in recent months than it has for years. This appears to be due to a couple of popular add-ons we use rather than Firefox itself, but the fact that a failing add-on can take out the entire Firefox process is itself a damning indictment of Firefox's basic process isolation and security model, which is still fundamentally flawed many years after every other major browser dealt with this issue.
Add-ons have literally unlimited access to the FireFox innards. That's by design. That's why FireFox add-ons are actually useful, compared for example to their castrated and harmless Chrome counterparts.
If you want to blame something, blame FireFox' rolling releases strategy. It's basically a cat and mouse game: browser changes, add-on authors has to change the add-ons, by the time they are finished, browser changes again.
That's a fair example, though my immediate question is why these plug-ins ever had direct access to things like keyboard input in the first place, given the obvious stability and security issues you mention.
Because plug-in requires at least a GUI widget. And a GUI widget has access to the event queue. On Mac and Linux that can be coded around - but on Windows you are stuck.
We've been running Java applets embedded within web pages for around two decades, and it's kind of absurd that in all that time and despite the rise and fall of other plug-ins like Flash and Silverlight along the way, browsers and operating systems haven't come up with a better model.
There is no better model currently which satisfies the performance and integration requirements. Plug-ins are black box binary libraries with hooks, allowing browsers to hook the plug-in into the browser. (That's why the browsers do the land grab they do, integrating everything possible or not inside them: they try to make out of the black boxes the white boxes. The obvious issue that leads to is the overstretching of the limited development resources. A team can handle only so much.)
Browsers already do the only effective thing they could do: run plug-ins in their own isolated processes.
P.S.
The only major browser that does not have major crash/hang bugs with any project I work on today is actually IE, which gets a bad rap for historical reasons but objectively has been vastly better in quality than Firefox, Chrome or Safari for several years now according to our bug trackers.
The greater irony (or more like "WTF" moment) is that some Google services actually work better in IE than in Chrome.
Rolling releases my ass. Everybody knows how IE works/doesn't work - stagnation is another word for stability. - nobody can be ever sure about the Chrome. Apparently even Google. Because its version number changes sometimes every day. (Well, it is easy to spot Chrome installing the updates: instead of the usual ~15s to fully start, it takes more than 30s.)
So tell me, what "suitable" language would allow the browser to parse 200-500K of minified JS code in under 0.5 second?
It's not as if I have a handy JS engine implemented in every safer language to benchmark, but there are plenty of them out there that compile down to speeds close enough to C that the difference is mostly academic.
Benchmarks in studio.
All comparisons I have seen so far were about executing JS code. But performance of data parsing is still largely sucks in all managed languages. And the modern web is overloaded by the ridiculous amount of the code. Parsing the JS nowadays takes more time than executing it. Because execution can be optimized to the bare necessary minimum, while one still has to parse the whole thing to know what to execute.
The trouble is, every one of them is currently in the range of "obscure" to "extremely obscure" and lacks the surrounding ecosystem to be a viable alternative today.
This is a highly specific task, really. And browsers have already literally excluded themselves from the rest of the software ecosystem. They come with their own network libraries, DNS libraries, security libraries, video/audio decoding libraries, GUI libraries and so on. Yes, on Linux, they can be configured to use the system libraries, but that wasn't the default behavior for many years now - distro devels have to activate that manually, and potentially deal with the incompatibility quirks.
Integration with 3rd parties is a bitch. That was and remains the main reason why plug-ins suck.
But going back, say, a decade, all of the major browsers integrated with all of the major plug-ins just fine.
Nope. Your memory is playing tricks with you.
Browser crashes due to plug-in bugs were the most often cause for browser crashes. And I have followed not one bugzilla ticket (in the times when "bugzilla" still was a term specific to Mozilla's Bugzilla) which involved lots of fingerpointing between Mozilla and Java/Flash developers.
The problems have been caused by deliberate decisions to drop support for various long-standing mechanism and/or an obvious lack of concern for even testing basic integration works. I don't for a moment believe that this was all done purely for technical reasons.
Here is a simple technical reason: keyboard input. There is no established interface, and generally the interface is highly OS specific, for a plug-in to pass an unhandled widget event (for example keyboard input) to the browser. That's why in some browsers still, if you open a tab with flash video, click inside the video and press ^W to close the tab, nothing happens. Because plug-in are the ^W and browser never seen it. Worst part: that is also a security concern: one can not let plug-ins simulate user's keyboard input, since that makes silent web-based keyloggers trivial to implement.
[...] they are also trying to write secure software in unsuitable programming languages like C++.
Right. So tell me, what "suitable" language would allow the browser to parse 200-500K of minified JS code in under 0.5 second? (200K == JQuery + few JQ plug-ins, 500K - JQuery + lots of JQ plug-ins.) Anyway, browsers already do resort to optimizations in assembler, because even C++ is not fast enough for what the web has become.
So now we can't use tried and tested plug-in technologies to actually make stuff, and we all have to use HTML5+JS instead, even though in some areas they are still far inferior to what we had before with Flash or Silverlight or Java applets.
Integration with 3rd parties is a bitch. That was and remains the main reason why plug-ins suck.
Portability is another big reason. Windows, iOS and Android do things in starkly different ways, making portable plug-ins even harder.
The problem are not plug-ins per se. The problem is that Google steers development of the Web toward its own goal which is to make the OSs obsolete. The short-sighted strategy resulted in overbloated browsers, with all the consequences for the security. Worse, they keep "optimizing" the browsers instead of e.g. integrating the JQuery/etc right into the browser to avoid repeating the loading of the same every time user clicks a link.
Just know that Germany is extremely protectionist on many fronts.
Recent discussions on GEZ or GEMA do not make me feel that there are lots of fans of them. The problem is that nobody can suggest a workable alternative.
But on-topic, Uber has to simply comply with the local law. The case in Frankfurt was heard in local court and its decision is only valid in state of Hessen. But the premise of the case was so simple that it didn't take long for judge to reach the verdict: Uber operates a taxi service, but doesn't comply with the relevant laws.
Uber's case has nothing to do with the stupidity the GEZ and the GEMA grew to be.
You can't even buy common off-the-shelf drugs that would cost $20 for a couple hundred in the US, but rather have to pay a pharmacy like a buck a piece for there.
I have absolutely no idea what you are talking about.
Just go to a doctor, complain, ask for a drug, and in all likelyhood they'll write you a prescription you want. (Just say the pill had helped you in the past. In most cases that is enough.)
And any (as in *any*) drug prescribed by a doctor costs 5 Euro, and the rest is payed by the health insurance.
Unless, of course, you try to abuse the system. But then it would the health insurance on your neck, trying to reimburse the costs. And they typically do not care, as long as you simply pay the bill for the drug. So I'm not really sure what's your problem.
But what I wouldn't do is go somewhere to blow up random civilians.
And that is why I think (historically) the democracy hasn't yet matured. Or probably even doesn't make any sense.
The big question about democracy is: who is responsible? those who were voted in the office? or those who voted them in?
The current "balance" is that nobody is responsible for anything. On the scale of the world, that is volatile and simply unsustainable.
And I certainly wouldn't pretend that God wanted me to do it.
"God" or "freedom" - there is really no difference between these imaginary entities. They are secondary anyway.
First people kill. Only then they look for a justification of their actions. Whatever makes people feel better about themselves or bear the guilt.
And let's be clear *skip*
That's a pretty senseless rant. Replace "Iran" with "Israel" and imaginary actions with real actions - and you are actually onto something.
And if there is going to be a war, I want the US to win it, because in the end, we'll at least try to do the right thing, and failing that, we'll leave.
Just like you did in Iraq. Very peaceful country. What they have? 10K civilian casualties per year? Very peaceful. Very freedom-y. And the best part: they owe you load of money for "freeing" them.
There were two kernel updates for 14.04 in a row recently so I checked things out. The only difference in the second update was that some network-related patch was removed since it was causing problems. There is a chance that your problem was fixed.
And it is good so, because it has nothing to do with "e-readers". Every single of the linked articles deals with the normal tablets, PCs and smartphones - e-readers are not even mentioned.
As somebody who switched to the Kindle several years ago, I had hard time believing the headline. As it turned out, the headline is full of bullshit and is not related to the content of the article.
Blocks that are normally indented now have to be closed explicitly with an end keyword.
I see what they did there.
Highly un-Python-ic: a new keyword to close the if/for/etc statements.
But it is a confirmation of my own conclusion that with the vanilla Python syntax that is impossible to accomplish.
Python support for me wasn't as important. I simply wanted to see and compare use of different languages in such context. And see whether a generic, language-neutral preprocessor makes any sense. (Here it is, btw.)
(Source: personal experience. I work on a Python IDE that has to deal with lots of that kind of stuff for e.g. implementation of refactoring. Once we had our whitespace-preserving AST, the rest was and remains easy.)
You have different use case, which is 100% controlled code. IOW, you can rely on the original indentation to create the AST.
where "user-*-code" is an arbitrary user supplied string.
If the user start/finish code is just a function call, then it is all fine.
But if the user code is "if something:{CR}{TAB}aaaa", then the user intent simply can't be made clear from the Python's syntax: (A) is it "if (something) { aaaa }" or (B) it is "if (something) { aaaa" (and the closing "bracket" is in the finish code).
I've spent few hours tinkering, but there is simply no way to tell A from B definitively in the Python's syntax.
P.S. It is a sort of preprocessor, which allows to mix plain text with an arbitrary language. In generated output, the plain text is simply replaced with the print statements.
On C/C++/Java code you can always run an formatter, and reformat it to your reading pleasure.
Ever wondered why there is no such tools for Python?
And I have seen enough of the crappy Python code too. It looks different from the C-like languages, but the shitty OOP is a shitty OOP in any OO language.
Different syntax is not a solution to any problem.
Wrappers for wrapper for adapters for wrappers - commonly found in the huge, so called "enterprise" software, is fluff.
In the case of Python, instead of intro/outro curled brackets or begin/end statements AND REDUNDANTLY indenting, using only one of the two was chosen. Why do it twice.
Language is a tool.
It should give me, the developer, the choice - not take it away from me.
As I have recently found out, that also affects the code generation.
It is hard to generate Python code, without actually analyzing what's precisely is being generated. If source is 100% generated - it is doable, relatively easy. But generally generated code also contains pieces of user code, which might/might not require its own indentation and also reindentation to make it proper part of the generated code.
If Python at least allowed optional block statement - curly brackets or begin/end or whatever. But nope. It is appears to be sort of a religious issue for the language creator and some of his followers.
I personally do not like Python for that reason. I prefer to have a visual marker that block is closed. You know, like a dot at the end of the sentence.
Slashdot Mirror
BASIC is every bit as modern as any other language and structurally equivalent to any modern static language. It's more verbose than C and similar languages [...]
Verbosity is the problem.
If I were fine with the screens and screens of the boilerplate code, I would have simply used the Java.
I don't understand why you couldn't get QtCreator working. Qt is easy to install and use on Ubuntu. And the Qt QUI designer is very easy to work with.
As I heard it was a systemic problem back then: not all package dependencies were declared, meaning that after installation you have to also install bunch of other stuff to make it working. (Many years ago, first time I tried QtCreator, it actually refused to run, because some linked libraries were missing.)
I'm not sure about now, but back then it wasn't even close to anything RAD. It was only a helper to create the GUI in a XML form, which was back then not even properly integrated with the rest: one had to write some code manually to actually tell Qt what resource corresponds to the window. And add resource manually to the resource file.
I would say that Python + libglade + glade is also a pretty good combination. It's not quite the RAD experience you seem to want, but it is a fast and powerful way of developing GUI apps, thanks go a nice API and Python.
Yes, it is not RAD. And for that I already use QT + C++, which provides very powerful, simple and no-fuss API to build GUIs dynamically (without external UI building tools like glade or Qt Designer).
The problem is not me per se - I have no problems with most of the stuff. The problem are the other team-members who are not well versed as me in the scripting languages and building GUIs. On many past projects I have left behind lots of stuff which 95% of coworkers can't support or develop further. And I want to solve the problem by throwing in something that requires as least boilerplate as possible, stays as close to demos/examples as possible. I'm simply trying to find something to help the people start moving in the right direction.
Xojo
Xubuntu 14.04 says that the installation would take 195MB of space. Bit heavy. Worst part: it is BASIC.
On the positive side, Lazarus + FP SDK, requires almost 1GB of space on my Xubuntu.
My ultimate goal is to be able to put together a quick UI, check in the source, and tell in few words to others who going to check it out how to compile it and get it running.
All in all, Xojo gets on the short list of things to try.
Only after I have pressed "Post" button, I hare realized that I probably given not enough context.
"Anything unique to a Linux developer who looks for RAD on Linux"?
From RAD for Linux, I'm aware only of the FreePascal-based Lazarus (Borland Delphi remake).
Past attempts with the KDevelop (and QtCreator) were pretty abysmal: right after "apt-get install" and few clicks to throw together UI, they were failing simply to compile the "Hello World" msgbox application. (And wild goose chase to install what was missing was counter the whole idea of *rapid* application development.)
Does Mono provide something unique to grant a look at it?
a generic Android phone?
There is no such thing as generic Android phone.
That became patently obvious to me when I have tried to buy a "generic" ARM board (Raspberry, Banana, Odroid) for Ubuntu.
It just doesn't exist.
There is no IMB/Intel/Microsoft aliance to help create and maintain a standard ARM-based platform. And it seems all vendors try to differentiate, making the devices slightly incompatible with each other.
The most ridiculous part is that past boot loader/after kernel is loaded, differences are minimal and can be expressed with the Linux' device tree. But it is apparent that nobody makes an effort even to catalog the differences. Google, with their rolling releases and "selected" devices, is simply oblivious to the rest of the market.
Which is closer to desktop Linux: Firefox OS, Sailfish, Ubuntu Touch, Cyanogenmod, OxygenOS, Tizen?
None. Or rather: Linux desktop with systemd and Wayland is headed the way of mobile phones.
Flashing ROM, if possible at all, is a nice thing to avoid. Any suggestions?
At least in the past, Samsung devices were recommended. They keep backup copy of the original OS on the flash, I was told. If you flash alternative OS and something goes wrong, you can still boot the original OS and repair/reinstall. (One of the reasons why CyanogenMod was originally developed on Samsung devices.) But I haven't tried that personally.
My FireFox on Ubuntu 14.04 routinely forgets the selected spellcheck language, and does not work until I select again the English (US).
So no, not PEBCAK. Just Mozilla doing their fine job as usual.
Long time ago I have read about. The crater was known about for many years now. But for it to be registered officially as an impact crater, they had to find the impact center and let other scientists review the work. When I read about it, they found the suspected impact center and were preparing for drilling. From the TFA, it seems that they have finally dug up the evidence, but I see no mention of it being officially confirmed.
Crater wasn't found. They have just dug up and analyzed the first samples. No mention of it being "confirmed". Though Wikipedia still lists it as unconfirmed.
For more info see: (excluding the "unconfirmed structures") List of impact craters on Earth, Earth Impact DB , (uncluding the unconfirmed ones) impact craters in Australia.
I really cannot understand why such a huge cheating effort seemed appropriate to these people.
Somebody tried to automate the exam taking? Without ever stepping inside a school?
The problem is not the size per se.
The problem is that every time you open a slashdot page, 1.1MB of (minified) JS code has to be parsed by the browser. Every damn Time.
No managed language (especially of the "everything is an object" garbage collected ones) are capable of parsing that in a reasonable time below 1s.
In dial-up times everything was slow because the "last mile" was slow. These days it is slow, because "web designers" effectively became a synonym to "mentally retarded hipsters".
Look at the slashdot. It would take probably 50-100 lines of PHP (or Perl/CGI) to create the main page and comments page(*) each, which would (A) take fraction of RAM/CPU resources and (B) load effectively at the speed the DB needs to fetch the data from disk (if they are not cached) (because disk is the slowest link in all that). Another smallish CGI for the login/logout. Throw in 50-100 lines of the CSS for the visual style. And probably 50 or so lines of the JS for the comment form. And another CGI for posting the comment in DB. And that's about 99% of the Slashdot I ever use. Now compare with the unmanageable clusterfuck we have. Or worse: compare to the beta.
(*) The tree organization of the comment might take bit more code.
I see where you coming from and actually I do not disagree with you.
Basically we just have different priorities.
Firefox has been hanging more for us in recent months than it has for years. This appears to be due to a couple of popular add-ons we use rather than Firefox itself, but the fact that a failing add-on can take out the entire Firefox process is itself a damning indictment of Firefox's basic process isolation and security model, which is still fundamentally flawed many years after every other major browser dealt with this issue.
Add-ons have literally unlimited access to the FireFox innards. That's by design. That's why FireFox add-ons are actually useful, compared for example to their castrated and harmless Chrome counterparts.
If you want to blame something, blame FireFox' rolling releases strategy. It's basically a cat and mouse game: browser changes, add-on authors has to change the add-ons, by the time they are finished, browser changes again.
That's a fair example, though my immediate question is why these plug-ins ever had direct access to things like keyboard input in the first place, given the obvious stability and security issues you mention.
Because plug-in requires at least a GUI widget. And a GUI widget has access to the event queue. On Mac and Linux that can be coded around - but on Windows you are stuck.
We've been running Java applets embedded within web pages for around two decades, and it's kind of absurd that in all that time and despite the rise and fall of other plug-ins like Flash and Silverlight along the way, browsers and operating systems haven't come up with a better model.
There is no better model currently which satisfies the performance and integration requirements. Plug-ins are black box binary libraries with hooks, allowing browsers to hook the plug-in into the browser. (That's why the browsers do the land grab they do, integrating everything possible or not inside them: they try to make out of the black boxes the white boxes. The obvious issue that leads to is the overstretching of the limited development resources. A team can handle only so much.)
Browsers already do the only effective thing they could do: run plug-ins in their own isolated processes.
P.S.
The only major browser that does not have major crash/hang bugs with any project I work on today is actually IE, which gets a bad rap for historical reasons but objectively has been vastly better in quality than Firefox, Chrome or Safari for several years now according to our bug trackers.
The greater irony (or more like "WTF" moment) is that some Google services actually work better in IE than in Chrome.
Rolling releases my ass. Everybody knows how IE works/doesn't work - stagnation is another word for stability. - nobody can be ever sure about the Chrome. Apparently even Google. Because its version number changes sometimes every day. (Well, it is easy to spot Chrome installing the updates: instead of the usual ~15s to fully start, it takes more than 30s.)
Slashdot is pretty "lightweight" and yet:
The size of JS embedded on this page I'm replying from is 33K in about 890 lines of code.
Externally loaded libraries are (most minimified):
http://a.fsdn.com/sd/all-minified.js?release_20150309
http://player.ooyala.com/v3/85...
http://a.fsdn.com/sd/html5.js
http://a.fsdn.com/sd/comments-...
http://www.googleadservices.co...
Total size: 1147446 bytes, aka 1.1MB.
You are welcome.
So tell me, what "suitable" language would allow the browser to parse 200-500K of minified JS code in under 0.5 second?
It's not as if I have a handy JS engine implemented in every safer language to benchmark, but there are plenty of them out there that compile down to speeds close enough to C that the difference is mostly academic.
Benchmarks in studio.
All comparisons I have seen so far were about executing JS code. But performance of data parsing is still largely sucks in all managed languages. And the modern web is overloaded by the ridiculous amount of the code. Parsing the JS nowadays takes more time than executing it. Because execution can be optimized to the bare necessary minimum, while one still has to parse the whole thing to know what to execute.
The trouble is, every one of them is currently in the range of "obscure" to "extremely obscure" and lacks the surrounding ecosystem to be a viable alternative today.
This is a highly specific task, really. And browsers have already literally excluded themselves from the rest of the software ecosystem. They come with their own network libraries, DNS libraries, security libraries, video/audio decoding libraries, GUI libraries and so on. Yes, on Linux, they can be configured to use the system libraries, but that wasn't the default behavior for many years now - distro devels have to activate that manually, and potentially deal with the incompatibility quirks.
Integration with 3rd parties is a bitch. That was and remains the main reason why plug-ins suck.
But going back, say, a decade, all of the major browsers integrated with all of the major plug-ins just fine.
Nope. Your memory is playing tricks with you.
Browser crashes due to plug-in bugs were the most often cause for browser crashes. And I have followed not one bugzilla ticket (in the times when "bugzilla" still was a term specific to Mozilla's Bugzilla) which involved lots of fingerpointing between Mozilla and Java/Flash developers.
The problems have been caused by deliberate decisions to drop support for various long-standing mechanism and/or an obvious lack of concern for even testing basic integration works. I don't for a moment believe that this was all done purely for technical reasons.
Here is a simple technical reason: keyboard input. There is no established interface, and generally the interface is highly OS specific, for a plug-in to pass an unhandled widget event (for example keyboard input) to the browser. That's why in some browsers still, if you open a tab with flash video, click inside the video and press ^W to close the tab, nothing happens. Because plug-in are the ^W and browser never seen it. Worst part: that is also a security concern: one can not let plug-ins simulate user's keyboard input, since that makes silent web-based keyloggers trivial to implement.
[...] they are also trying to write secure software in unsuitable programming languages like C++.
Right. So tell me, what "suitable" language would allow the browser to parse 200-500K of minified JS code in under 0.5 second? (200K == JQuery + few JQ plug-ins, 500K - JQuery + lots of JQ plug-ins.) Anyway, browsers already do resort to optimizations in assembler, because even C++ is not fast enough for what the web has become.
So now we can't use tried and tested plug-in technologies to actually make stuff, and we all have to use HTML5+JS instead, even though in some areas they are still far inferior to what we had before with Flash or Silverlight or Java applets.
Integration with 3rd parties is a bitch. That was and remains the main reason why plug-ins suck.
Portability is another big reason. Windows, iOS and Android do things in starkly different ways, making portable plug-ins even harder.
The problem are not plug-ins per se. The problem is that Google steers development of the Web toward its own goal which is to make the OSs obsolete. The short-sighted strategy resulted in overbloated browsers, with all the consequences for the security. Worse, they keep "optimizing" the browsers instead of e.g. integrating the JQuery/etc right into the browser to avoid repeating the loading of the same every time user clicks a link.
Just know that Germany is extremely protectionist on many fronts.
Recent discussions on GEZ or GEMA do not make me feel that there are lots of fans of them. The problem is that nobody can suggest a workable alternative.
But on-topic, Uber has to simply comply with the local law. The case in Frankfurt was heard in local court and its decision is only valid in state of Hessen. But the premise of the case was so simple that it didn't take long for judge to reach the verdict: Uber operates a taxi service, but doesn't comply with the relevant laws.
Uber's case has nothing to do with the stupidity the GEZ and the GEMA grew to be.
You can't even buy common off-the-shelf drugs that would cost $20 for a couple hundred in the US, but rather have to pay a pharmacy like a buck a piece for there.
I have absolutely no idea what you are talking about.
Just go to a doctor, complain, ask for a drug, and in all likelyhood they'll write you a prescription you want. (Just say the pill had helped you in the past. In most cases that is enough.)
And any (as in *any*) drug prescribed by a doctor costs 5 Euro, and the rest is payed by the health insurance.
Unless, of course, you try to abuse the system. But then it would the health insurance on your neck, trying to reimburse the costs. And they typically do not care, as long as you simply pay the bill for the drug. So I'm not really sure what's your problem.
But what I wouldn't do is go somewhere to blow up random civilians.
And that is why I think (historically) the democracy hasn't yet matured. Or probably even doesn't make any sense.
The big question about democracy is: who is responsible? those who were voted in the office? or those who voted them in?
The current "balance" is that nobody is responsible for anything. On the scale of the world, that is volatile and simply unsustainable.
And I certainly wouldn't pretend that God wanted me to do it.
"God" or "freedom" - there is really no difference between these imaginary entities. They are secondary anyway.
First people kill. Only then they look for a justification of their actions. Whatever makes people feel better about themselves or bear the guilt.
And let's be clear *skip*
That's a pretty senseless rant. Replace "Iran" with "Israel" and imaginary actions with real actions - and you are actually onto something.
And if there is going to be a war, I want the US to win it, because in the end, we'll at least try to do the right thing, and failing that, we'll leave.
Just like you did in Iraq. Very peaceful country. What they have? 10K civilian casualties per year? Very peaceful. Very freedom-y. And the best part: they owe you load of money for "freeing" them.
Check the Ubuntu kernel updates again.
There were two kernel updates for 14.04 in a row recently so I checked things out. The only difference in the second update was that some network-related patch was removed since it was causing problems. There is a chance that your problem was fixed.
I only skimmed the summary.
And it is good so, because it has nothing to do with "e-readers". Every single of the linked articles deals with the normal tablets, PCs and smartphones - e-readers are not even mentioned.
As somebody who switched to the Kindle several years ago, I had hard time believing the headline. As it turned out, the headline is full of bullshit and is not related to the content of the article.
If you wish, even C:
#define BEGIN {
#define END }
And C++ has some of that already built-in.
Blocks that are normally indented now have to be closed explicitly with an end keyword.
I see what they did there.
Highly un-Python-ic: a new keyword to close the if/for/etc statements.
But it is a confirmation of my own conclusion that with the vanilla Python syntax that is impossible to accomplish.
Python support for me wasn't as important. I simply wanted to see and compare use of different languages in such context. And see whether a generic, language-neutral preprocessor makes any sense. (Here it is, btw.)
(Source: personal experience. I work on a Python IDE that has to deal with lots of that kind of stuff for e.g. implementation of refactoring. Once we had our whitespace-preserving AST, the rest was and remains easy.)
You have different use case, which is 100% controlled code. IOW, you can rely on the original indentation to create the AST.
My use case is:
{user-start-code}
{generated-code}
{user-finish-code}
where "user-*-code" is an arbitrary user supplied string.
If the user start/finish code is just a function call, then it is all fine.
But if the user code is "if something:{CR}{TAB}aaaa", then the user intent simply can't be made clear from the Python's syntax: (A) is it "if (something) { aaaa }" or (B) it is "if (something) { aaaa" (and the closing "bracket" is in the finish code).
I've spent few hours tinkering, but there is simply no way to tell A from B definitively in the Python's syntax.
P.S. It is a sort of preprocessor, which allows to mix plain text with an arbitrary language. In generated output, the plain text is simply replaced with the print statements.
Oh this is just a load of.
On C/C++/Java code you can always run an formatter, and reformat it to your reading pleasure.
Ever wondered why there is no such tools for Python?
And I have seen enough of the crappy Python code too. It looks different from the C-like languages, but the shitty OOP is a shitty OOP in any OO language.
Different syntax is not a solution to any problem.
Wow.
Removing the ability to screw things up is NOT a bad thing
Can you please elaborate how use of whitespaces for defining control flow is "removing the ability to screw things up"?
If nothing else, use of the invisible characters for something as important as control flow is actively helping "the ability to screw things up".
But does that mean I'm going to poo-poo those languages or try to pretend they're inferior?
The problem is, Python is inferior. Because it provides less tools to its developers.
It's not like C lets you change which brackets do what, does it?
But C does have at least some brackets.
It does have clear visual clues and delimiters in its syntax.
Haha, here you all complain that Java is too fluffy, but if a language reduces the fluff it is also not good?
Oh this hipster coders.
Syntax is not fluff.
Wrappers for wrapper for adapters for wrappers - commonly found in the huge, so called "enterprise" software, is fluff.
In the case of Python, instead of intro/outro curled brackets or begin/end statements AND REDUNDANTLY indenting, using only one of the two was chosen. Why do it twice.
Language is a tool.
It should give me, the developer, the choice - not take it away from me.
As I have recently found out, that also affects the code generation.
It is hard to generate Python code, without actually analyzing what's precisely is being generated. If source is 100% generated - it is doable, relatively easy. But generally generated code also contains pieces of user code, which might/might not require its own indentation and also reindentation to make it proper part of the generated code.
If Python at least allowed optional block statement - curly brackets or begin/end or whatever. But nope. It is appears to be sort of a religious issue for the language creator and some of his followers.
I personally do not like Python for that reason. I prefer to have a visual marker that block is closed. You know, like a dot at the end of the sentence.
... it is unclear...
But that would have made a pretty poor headline or summary.