Believing that humans can control or ultimately break any paradigm in this planet's existence is pure nonsense and the ultimate hubris.
Well, we do have the power to nuke the absolute crap out of it, and we're making a whole bunch of species extinct. But I'm guessing those somehow doesn't count?
Good job on the Internet rage, AC. With that level of maturity, it's little wonder you find yourself getting banned.
This thread is about a scam Ethernet cable. If you meant analog audio cabling, you should've said. You don't get to call everyone else stupid for failing to have guessed it.
the company where I worked was fooled into buying one of these for my computer, when the program I was using required one of the higher-spec devices. That misleading advertising actually did real financial damage
What exactly did they lie about? It sounds like you needed a card with support for new graphics APIs, and it turned out it didn't have that support, correct? Surely that's the fault of the person who placed the order.
Creating a 'GeForce 4' that's actually less capable than a 'GeForce 3' is at worst a bit scummy (at worse.... it's not totally unreasonable to have a low-end GF4 be outperformed by a high-end GF3, imo). I wouldn't go as far as to say it was misleading advertising, unless they really lied on the check-boxes about supported graphics APIs.
Sure it doesn't really matter a damn, but it would at least be in some sense technically superior, in a way very slightly less irrelevant that 'ooh fancy theoretical properties of the conductor'.
Timing may matter, but it's something I'd rather trust to a sensible logic and a big enough buffer to cover the "rough" times rather than spending a fortune on a cable that can't even sensibly promise this
If the cable actually helped with these unimportant 'rough times' (something that's actually measurable), I'm sure they'd be shouting about it.
Additionally, binding-generators like SWIG already do a very good job of removing unnecessary complexity from the task of getting different languages to communicate.
we already have the capability to cross-call from pretty much any language to any other (with varying degrees of difficulty)
It's that 'difficulty' which I'm referring to. Mapping C++ constructs onto Haskell (or vice versa) isn't trivial.
I imagine that the constraints of pure FP would obviate a lot of the incompatibilities, as you would be able to call FP subsystem from anywhere
What about lazy-evaluation vs eager? What about static vs dynamic type systems? It isn't the case that all functions are created equal.
I may be missing something, but concurrency and parallelism seem trivial for immutable items
But real-life C++ code doesn't tend to make extensive use of immutable objects, and for good reasons.
If you strip away all of the hacks that allow you to do things that are not appropriate to the paradigm, integration would be simplified
No. This isn't like Lego. The differences between the languages are considerable. If you want Java or C# to play nice with C++ objects, managed by C++ smart-pointers for reference counting, you have no choice but to reinvent C++ inside Java. (As I understand it this is kinda what 'Managed C++' does.) Likewise if you want Java objects to be accessible from C++, you either have to start pinning objects to block the Java garbage-collector from moving the object, or integrate C++ into the JVM's world.
There's a reason that nice bindings take some effort.
I would like to see a multi paradigm "multi language"
But this isn't possible. The differences between languages aren't just skin-deep. For instance, Haskell's lazy-evaluation really is a world away from the sequential-execution paradigm used in imperative languages. These differences run deep enough that they use quite different compiler frameworks.
Similar fundamental incompatibilities exist for type-systems, memory-management strategies, approaches to concurrency and parallelism...
I agree that it's quite possible the web would be a better place if JavaScript used a bytecode system of some sort, but I don't think a 'grand unified framework' is practical (well, excluding a very low-level 'portable assembly' representation, which I don't think is really what you mean).
This is a theoretical question, because "here in the real world", there is no declarative functional language to benchmark against.
Then I really don't care. You're talking about such a narrow set of language - so narrow that you concede no such languages even exist - that it's really not worth our time to reason about them from a practical, software engineering perspective.
What 'concessions' Haskell makes are in the name of practicality, and it's still nowhere near a practical language, really, at least not judging by its uptake.
If you're seriously going to argue for adoption of ultra-pure functional programming languages, you've got your work cut out.
a compiler should be able to handle performance for us. One of the reasons compiler optimisations are so difficult is down to the multitude of ways imperative programming can be hacked about
But this simply isn't true. Here in the real world, C, C++, and FORTRAN are incredibly fast. Faster than Haskell or OCaml.
This isn't a theoretical question. Real C code can generally be expected to outperform real Haskell code. (Yes, carefully tuned Haskell code can be fast too.)
Your points don't matter. There's enough of a correlation that it's worthwhile. Of course there are no absolute guarantees. There never are, in anything.
Here in the UK, taxi drivers are background-checked, as well as required to pass a stricter driving-test than ordinary drivers. If these restrictions were removed, we would see an increase in taxi-driver crimes and accidents. It really doesn't take a genius...
FP has been hamstrung by people fixating on ML, Lisp etc, and forgetting that much of how they do things is determined by the memory and processor constraints of machines 40 or 50 years ago.
we have a hell of a lot more resources to play with, so we can do things a bit more clever, surely?
So you're really just saying performance be damned, functional programming is great, right?
I'm not opposed to FP, but I disagree that performance doesn't matter. High-performance is a great thing for in-browser scripting. It's an enabler. It means neat things like WebGL (against which there are many valid complaints, but I'll ignore those for now) might actually be useful, and not just an interesting gimmick. Asm.js is exciting precisely because it enables really fast code to run in the browser, within the usual execution model.
A slight aside: bloated, pointless use of JavaScript is already a plague on browser-compatibility, mobile-device power-consumption, security (because it discourages use of things like NoScript, which really do improve security) and sometimes even causes overheating. If JavaScript were less efficient, such idiotic abuses of it would be that bit worse.
Slashdot Mirror
Desktop are by definition bigger than laptops so they can dissipate more heat.
What if my lap is bigger than my desk?
Believing that humans can control or ultimately break any paradigm in this planet's existence is pure nonsense and the ultimate hubris.
Well, we do have the power to nuke the absolute crap out of it, and we're making a whole bunch of species extinct. But I'm guessing those somehow doesn't count?
On SoylentNews there's more of a no-clickbait-or-advertising-bullshit culture. Are you a member?
No-one can deny Bitcoin is convenient for criminal dealings.
So are vans and baseball bats.
No it's not. Of course it's not.
Good job on the Internet rage, AC. With that level of maturity, it's little wonder you find yourself getting banned.
This thread is about a scam Ethernet cable. If you meant analog audio cabling, you should've said. You don't get to call everyone else stupid for failing to have guessed it.
the company where I worked was fooled into buying one of these for my computer, when the program I was using required one of the higher-spec devices. That misleading advertising actually did real financial damage
What exactly did they lie about? It sounds like you needed a card with support for new graphics APIs, and it turned out it didn't have that support, correct? Surely that's the fault of the person who placed the order.
Creating a 'GeForce 4' that's actually less capable than a 'GeForce 3' is at worst a bit scummy (at worse.... it's not totally unreasonable to have a low-end GF4 be outperformed by a high-end GF3, imo). I wouldn't go as far as to say it was misleading advertising, unless they really lied on the check-boxes about supported graphics APIs.
Sure it doesn't really matter a damn, but it would at least be in some sense technically superior, in a way very slightly less irrelevant that 'ooh fancy theoretical properties of the conductor'.
After unpacking them. And error checking/correcting them.
And of course running the resulting bits through the digital->analog converter, the quality of which really does actually matter.
Why is it that almost literally all the idiotic garbage on Slashdot is from ACs?
Timing may matter, but it's something I'd rather trust to a sensible logic and a big enough buffer to cover the "rough" times rather than spending a fortune on a cable that can't even sensibly promise this
If the cable actually helped with these unimportant 'rough times' (something that's actually measurable), I'm sure they'd be shouting about it.
Well, a company that charges ten thousand US dollars for a network cable may easily pay very good money to have favorable "reviews"
Assuming people actually shell out thousands for the cables in the first place.
As a non-American I am surprised as you Americans allow criminals freely sell products that are clearly scams like this.
What's sold as 'alternative medicine' is a more worrying instance.
Additionally, binding-generators like SWIG already do a very good job of removing unnecessary complexity from the task of getting different languages to communicate.
we already have the capability to cross-call from pretty much any language to any other (with varying degrees of difficulty)
It's that 'difficulty' which I'm referring to. Mapping C++ constructs onto Haskell (or vice versa) isn't trivial.
I imagine that the constraints of pure FP would obviate a lot of the incompatibilities, as you would be able to call FP subsystem from anywhere
What about lazy-evaluation vs eager? What about static vs dynamic type systems? It isn't the case that all functions are created equal.
I may be missing something, but concurrency and parallelism seem trivial for immutable items
But real-life C++ code doesn't tend to make extensive use of immutable objects, and for good reasons.
If you strip away all of the hacks that allow you to do things that are not appropriate to the paradigm, integration would be simplified
No. This isn't like Lego. The differences between the languages are considerable. If you want Java or C# to play nice with C++ objects, managed by C++ smart-pointers for reference counting, you have no choice but to reinvent C++ inside Java. (As I understand it this is kinda what 'Managed C++' does.) Likewise if you want Java objects to be accessible from C++, you either have to start pinning objects to block the Java garbage-collector from moving the object, or integrate C++ into the JVM's world.
There's a reason that nice bindings take some effort.
you can call them "fakes", but they are made in the same factory by the same workers as the "real ones"
But are they the same device?
A single factory and workforce might produce any number of different products.
No no no no no. It's not good trolling if you reveal yourself like that.
Unless my Ctrl-f is acting up, the article doesn't even contain the word 'electricity'....
Is this actually a thing? If so, is it going to be unmetered?
Let go. Genocides do solves everything.
Riiiight.... so in your estimation, what proportion of genocides result in responsible politics that serve the populace?
I would like to see a multi paradigm "multi language"
But this isn't possible. The differences between languages aren't just skin-deep. For instance, Haskell's lazy-evaluation really is a world away from the sequential-execution paradigm used in imperative languages. These differences run deep enough that they use quite different compiler frameworks.
Similar fundamental incompatibilities exist for type-systems, memory-management strategies, approaches to concurrency and parallelism...
I agree that it's quite possible the web would be a better place if JavaScript used a bytecode system of some sort, but I don't think a 'grand unified framework' is practical (well, excluding a very low-level 'portable assembly' representation, which I don't think is really what you mean).
What's your opinion of Asm.js?
This is a theoretical question, because "here in the real world", there is no declarative functional language to benchmark against.
Then I really don't care. You're talking about such a narrow set of language - so narrow that you concede no such languages even exist - that it's really not worth our time to reason about them from a practical, software engineering perspective.
What 'concessions' Haskell makes are in the name of practicality, and it's still nowhere near a practical language, really, at least not judging by its uptake.
If you're seriously going to argue for adoption of ultra-pure functional programming languages, you've got your work cut out.
a compiler should be able to handle performance for us. One of the reasons compiler optimisations are so difficult is down to the multitude of ways imperative programming can be hacked about
But this simply isn't true. Here in the real world, C, C++, and FORTRAN are incredibly fast. Faster than Haskell or OCaml.
This isn't a theoretical question. Real C code can generally be expected to outperform real Haskell code. (Yes, carefully tuned Haskell code can be fast too.)
Your points don't matter. There's enough of a correlation that it's worthwhile. Of course there are no absolute guarantees. There never are, in anything.
Here in the UK, taxi drivers are background-checked, as well as required to pass a stricter driving-test than ordinary drivers. If these restrictions were removed, we would see an increase in taxi-driver crimes and accidents. It really doesn't take a genius...
FP has been hamstrung by people fixating on ML, Lisp etc, and forgetting that much of how they do things is determined by the memory and processor constraints of machines 40 or 50 years ago.
we have a hell of a lot more resources to play with, so we can do things a bit more clever, surely?
So you're really just saying performance be damned, functional programming is great, right?
I'm not opposed to FP, but I disagree that performance doesn't matter. High-performance is a great thing for in-browser scripting. It's an enabler. It means neat things like WebGL (against which there are many valid complaints, but I'll ignore those for now) might actually be useful, and not just an interesting gimmick. Asm.js is exciting precisely because it enables really fast code to run in the browser, within the usual execution model.
A slight aside: bloated, pointless use of JavaScript is already a plague on browser-compatibility, mobile-device power-consumption, security (because it discourages use of things like NoScript, which really do improve security) and sometimes even causes overheating. If JavaScript were less efficient, such idiotic abuses of it would be that bit worse.
Does this include ".NET Native", where they compile ahead-of-time using the same backend Visual Studio uses for C++?
Spotify explain their revenue-model and payout-model here.
Right, then your issue is not with Gmail, but with deep Google account integration into Android.
I happen to agree: I'd far rather my phone be clear about these things.