Hi! We're trying to build out a comprehensive set of resources for people wanting to start a repair business ([1], [2]), and we'd love to have any feedback or suggestions you might have. Information on the most common repairs, like what you've just provided, is an excellent example of the type of thing we're wanting to make more common knowledge.
Contrary to whatever silly fantasy world you live in, 99.9999% of the population DOES NOT GIVE A SHIT ABOUT DISASSEMBLING THEIR PHONE. They just use the damn thing.
They use it until they crack the screen; then they want a non-broken phone.
But these serve different purposes. The kind of app you'd use Sinatra for is the kind of app Rails would be worse at, and vice versa. Sinatra is more in the same space as Camping, and I don't know if anyone still uses Camping.
Sure, but hasn't the Python community kinda imbraced Django as the One True fullstack framework?
Excuse me... Free has little to do with price. And in the case of GPL and LGPL, the price is as follows: "If you use the software you have to provide the source and any possible modifications you might have made to the people you sold/gave the software to." That's the price. Whether you view it as worth nothing or priceless all is in whether you're just a user or a developer.
Well, to be pedantic, that is the *cost* of the (L)GPL. The price is 0.
How exactly do you put something into public domain legally, such that you can legally protect them to be in public domain?
In some countries, you can't really. That's why we have the WTFPL. The Wikipedia article says there are only 11 uses of it on Freshmeat, but it's rather commonly used on GitHub.
That's OK. Maybe some day Slashcode will actually render <comic book guy> and </comic book guy> tags. About the time they decide to implement more than 2% of the HTML entity set.
Of course, by that time, everyone else will have been using Markdown (or similar) for 10 years.
My statement is still valid. you hand someone your card to pay for gas, they can go in and duplicate it very easily with a magnetic stripe just by swiping it through a reader.
You go inside to pay for gas? I just use the cardswipe/pinpad on the gas pump, which I thought was pretty standard practice these days.
Because everyone chooses a language based on raw execution speed, amirite?
You were comparing relative increases between different implementations of one language before; now you're comparing the fastest implementation of one language to the not-fastest implementations of others. =_=
Even if they look vaguely similar on the surface, all of the languages you've mentioned are quite different internally. Some performance changes that would take too much effort to change, some won't happen for philosophical reasons, and a great deal more are not applicable to anything other than the language they were written for.
> There's "fat-val", "tracer JIT" and "method JIT".
Just curious, given all these advances in JS speed, are there technical reasons why stuff like Python, Ruby and Perl aren't getting similar improvements in speed?
Perl... well, it's either dead or incredibly alive, depending on who you ask, but all development seems to be focused on Perl6.
Ruby doesn't have an "official" interpreter. The standard C implementation uses YARV for 1.9, which is considerably better than MRI (which was in 1.8). Rubinius is supposed to be faster, but isn't quite ready yet. Ruby Enterprise Edition seems to be fairly popular, but doesn't have 1.9 compatability yet. I believe JRuby is fairly widely-used, and it seems that it can perform better than YARV sometimes (and consistently better than MRI).
On the Python front, Unladen Swallow seems to be chugging along, although I'm not sure what we'll get out of it. PyPy is quite promising, and is faster than CPython in many benchmarks.
Nowhere. But right now it's the most widely adopted and implemented (pretty much everyone but Firefox either does or is planning to support it).
And pretty much everyone except Apple is planning on supporting WebM (or is, currently). Sure, IE will only support it if a vp8 codec is installed on the machine, but that counts enough for me.
if they think that Google, who provides about 85% of Mozilla's total revenue, is going to sit back and let them take the technical lead over Chrome, they're nuts.
Except that Google benefits from faster Javascript engines in any browser, not just Chrome. Firefox is a popular browser, and if Firefox can execute Javascript faster, that means that Google's web apps (which I am just going to guess account for more revenue than Chrome) will perform better. It also means that Google could potentially do more, i.e. have heavier Javascript programs, without worrying that people are going to get annoyed at how slow their applications are. How does Google lose here?
It was my impression that Google created Chrome primarily to push browser speeds (in particular, javascript) forward. Mozilla wouldn't be nearly so concerned with it now if it weren't for V8.
You misunderstood what I was saying - unit tests should be testing functionality, rather than error handling on every possible type of input, etc. My phrasing was rather misleading, so I'll take the blame for that one.
I should also make the point that dynamically-typed languages do not necessarily allow variables to be used without declaration. `var foo` would be a perfectly acceptable statement (and is, I believe, how C# handles implicitly-typed variables), but none of the (popular) dynamically-typed languages of today have such a thing.
Correct me if I'm wrong here, but I believe Droid was marketed as being based on the Java language as opposed to being an implementation of the Java spec.
Well, first off, Droid is a phone produced by Motorola, while Android is the platform that runs on it. Secondly, Android is an operating system, not a programming language; Dalvik is probably the term you wanted to use, but even that's not truly accurate, as it is a virtual machine. I'm not sure what Google refers to the primary language running on Dalvik as, but iirc they call it Java.
My apologies for being pedantic, but this is Slashdot.
For example, on a current project, we have standardised JSON data that is accessed using several different programming languages in different contexts. In JavaScript or Python, it’s a breeze. In Java, it’s a chore.
Of course, if you're using Java, it's likely you'll also use XML, to make your application more "enterprisey".
While dynamic-typing weenies like myself see no need for schema validations, many classmates of mine seem to think it's a much better idea than receiving a data structure that may or may not be what you want. It's a difference in philosophy.
Given the history of web development, dynamic languages became widely used mainly out of ignorance, and have remained widely used due to continuing ignorance. There's no technical argument in favor of dynamic languages. They're just used because their users and proponents often don't even know about how much better and easier static languages make the development of both small and large applications.
While I agree with much of your comment, I believe there are reasons for the continued use of scripting languages in web dev, other than ignorance or stupidity.
The web moves fast, and scripting languages, with their lack of compile-run cycle allow quicker development. Things change enough that this is often worth the corresponding drop in execution speed.
Secondly, the widely-used statically-typed languages (Java, C#) are about as non-DRY as you can get, Java in particular. While static typing does not necessitate needless boilerplate, the languages that remove it are only now starting to gain acceptance, and haven't gotten a firm hold on the market (or strong communities) yet.
Thirdly, shared web hosts (where the majority of small businesses and personal sites are hosted) often don't support much other than static files and PHP, possibly ASP (.NET or otherwise, I haven't checked in a while). I've recently switched to doing a lot more static sites generated by Jekyll, simply because GitHub will host it for me for free (and only having to push my git commits to deploy is nice, too). Hosting matters.
Finally, I find that community is far more important than the language itself, and the innovating part of the web community is a fickle beast, but tends to stay in the realm of dynamically-typed languages. It takes a few years to get something roughly as nice as Rails (well... other people like it) or Django, and years are decades in our field. Things like HAML have been ported to.NET and Java, but the development's done in Ruby.
Slashdot Mirror
Generally you purchase a screen from eBay or various other places, then use our (iFixit's) guides to replace the old with the new.
Having the correct tools does not magically make broken things unbroken, but it helps you to repair them.
Hi! We're trying to build out a comprehensive set of resources for people wanting to start a repair business ([1], [2]), and we'd love to have any feedback or suggestions you might have. Information on the most common repairs, like what you've just provided, is an excellent example of the type of thing we're wanting to make more common knowledge.
They use it until they crack the screen; then they want a non-broken phone.
We do.
Ruby 3.0 is a long ways off. You probably want Rails 3.0 and Ruby 1.9.
Embraced, dammit.
But these serve different purposes. The kind of app you'd use Sinatra for is the kind of app Rails would be worse at, and vice versa. Sinatra is more in the same space as Camping, and I don't know if anyone still uses Camping.
Sure, but hasn't the Python community kinda imbraced Django as the One True fullstack framework?
Excuse me... Free has little to do with price. And in the case of GPL and LGPL, the price is as follows: "If you use the software you have to provide the source and any possible modifications you might have made to the people you sold/gave the software to." That's the price. Whether you view it as worth nothing or priceless all is in whether you're just a user or a developer.
Well, to be pedantic, that is the *cost* of the (L)GPL. The price is 0.
I am not an economist.
How exactly do you put something into public domain legally, such that you can legally protect them to be in public domain?
In some countries, you can't really. That's why we have the WTFPL. The Wikipedia article says there are only 11 uses of it on Freshmeat, but it's rather commonly used on GitHub.
That's OK. Maybe some day Slashcode will actually render <comic book guy> and </comic book guy> tags. About the time they decide to implement more than 2% of the HTML entity set.
Of course, by that time, everyone else will have been using Markdown (or similar) for 10 years.
My statement is still valid. you hand someone your card to pay for gas, they can go in and duplicate it very easily with a magnetic stripe just by swiping it through a reader.
You go inside to pay for gas? I just use the cardswipe/pinpad on the gas pump, which I thought was pretty standard practice these days.
The reason we complain so much about electronic voting systems is because all of the ones used in the U.S. are horribly insecure.
So in summary they haven't been getting similar improvements in speed.
Perhaps that's because they didn't suck so much in the first place (with the possible exception of MRI)?
After all, Javascript is now faster (except for pi and reverse-complement).
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=yarv
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=python3
Because everyone chooses a language based on raw execution speed, amirite?
You were comparing relative increases between different implementations of one language before; now you're comparing the fastest implementation of one language to the not-fastest implementations of others. =_=
Even if they look vaguely similar on the surface, all of the languages you've mentioned are quite different internally. Some performance changes that would take too much effort to change, some won't happen for philosophical reasons, and a great deal more are not applicable to anything other than the language they were written for.
> There's "fat-val", "tracer JIT" and "method JIT". Just curious, given all these advances in JS speed, are there technical reasons why stuff like Python, Ruby and Perl aren't getting similar improvements in speed?
Perl... well, it's either dead or incredibly alive, depending on who you ask, but all development seems to be focused on Perl6.
Ruby doesn't have an "official" interpreter. The standard C implementation uses YARV for 1.9, which is considerably better than MRI (which was in 1.8). Rubinius is supposed to be faster, but isn't quite ready yet. Ruby Enterprise Edition seems to be fairly popular, but doesn't have 1.9 compatability yet. I believe JRuby is fairly widely-used, and it seems that it can perform better than YARV sometimes (and consistently better than MRI).
On the Python front, Unladen Swallow seems to be chugging along, although I'm not sure what we'll get out of it. PyPy is quite promising, and is faster than CPython in many benchmarks.
Nowhere. But right now it's the most widely adopted and implemented (pretty much everyone but Firefox either does or is planning to support it).
And pretty much everyone except Apple is planning on supporting WebM (or is, currently). Sure, IE will only support it if a vp8 codec is installed on the machine, but that counts enough for me.
if they think that Google, who provides about 85% of Mozilla's total revenue, is going to sit back and let them take the technical lead over Chrome, they're nuts.
Except that Google benefits from faster Javascript engines in any browser, not just Chrome. Firefox is a popular browser, and if Firefox can execute Javascript faster, that means that Google's web apps (which I am just going to guess account for more revenue than Chrome) will perform better. It also means that Google could potentially do more, i.e. have heavier Javascript programs, without worrying that people are going to get annoyed at how slow their applications are. How does Google lose here?
It was my impression that Google created Chrome primarily to push browser speeds (in particular, javascript) forward. Mozilla wouldn't be nearly so concerned with it now if it weren't for V8.
Sure, but you can't fix a bug until you know about it, and once it was found out, it was fixed, quickly.
Do Behavior Driven Development with Cucumber http://cukes.info./
... or one of the many non-Ruby tools.
You misunderstood what I was saying - unit tests should be testing functionality, rather than error handling on every possible type of input, etc. My phrasing was rather misleading, so I'll take the blame for that one.
I should also make the point that dynamically-typed languages do not necessarily allow variables to be used without declaration. `var foo` would be a perfectly acceptable statement (and is, I believe, how C# handles implicitly-typed variables), but none of the (popular) dynamically-typed languages of today have such a thing.
[H]ow long has it been since Java was associated with something cool?
Well, supposedly they're cool right now. I just mentally s/Java/Ruby\/Python/ and s/.NET/Java/ when I watched that video, and it made much more sense.
Correct me if I'm wrong here, but I believe Droid was marketed as being based on the Java language as opposed to being an implementation of the Java spec.
Well, first off, Droid is a phone produced by Motorola, while Android is the platform that runs on it. Secondly, Android is an operating system, not a programming language; Dalvik is probably the term you wanted to use, but even that's not truly accurate, as it is a virtual machine. I'm not sure what Google refers to the primary language running on Dalvik as, but iirc they call it Java.
My apologies for being pedantic, but this is Slashdot.
The headline "Microsoft May Back Off dynamic .NET Languages" would be better?
That depends on whether you define "better" as "more accurate" or "will get more clicks".
I've been hoping for COBOL.NET.
I guess you'll have to satisfy yourself with COBOL ON COGS in the meantime.
For example, on a current project, we have standardised JSON data that is accessed using several different programming languages in different contexts. In JavaScript or Python, it’s a breeze. In Java, it’s a chore.
Of course, if you're using Java, it's likely you'll also use XML, to make your application more "enterprisey".
While dynamic-typing weenies like myself see no need for schema validations, many classmates of mine seem to think it's a much better idea than receiving a data structure that may or may not be what you want. It's a difference in philosophy.
Given the history of web development, dynamic languages became widely used mainly out of ignorance, and have remained widely used due to continuing ignorance. There's no technical argument in favor of dynamic languages. They're just used because their users and proponents often don't even know about how much better and easier static languages make the development of both small and large applications.
While I agree with much of your comment, I believe there are reasons for the continued use of scripting languages in web dev, other than ignorance or stupidity.
The web moves fast, and scripting languages, with their lack of compile-run cycle allow quicker development. Things change enough that this is often worth the corresponding drop in execution speed.
Secondly, the widely-used statically-typed languages (Java, C#) are about as non-DRY as you can get, Java in particular. While static typing does not necessitate needless boilerplate, the languages that remove it are only now starting to gain acceptance, and haven't gotten a firm hold on the market (or strong communities) yet.
Thirdly, shared web hosts (where the majority of small businesses and personal sites are hosted) often don't support much other than static files and PHP, possibly ASP (.NET or otherwise, I haven't checked in a while). I've recently switched to doing a lot more static sites generated by Jekyll, simply because GitHub will host it for me for free (and only having to push my git commits to deploy is nice, too). Hosting matters.
Finally, I find that community is far more important than the language itself, and the innovating part of the web community is a fickle beast, but tends to stay in the realm of dynamically-typed languages. It takes a few years to get something roughly as nice as Rails (well... other people like it) or Django, and years are decades in our field. Things like HAML have been ported to .NET and Java, but the development's done in Ruby.