I'm still not convinced that Option have any value. It looks more that it complicates development and is only here for null-phobic developers. But thank you for your time.
Java has checked exceptions. C# has unchecked exceptions. Option types are similar to Java's checked exceptions
How does Option helps in find(), search(), indexOf()? Why not just use exceptions or return null?
If a function can't return a meaningful value, it looks for me like a code smell. It should always return a meaningful value or throw an exception. The return of -1 in the find() method is a code smell and just bad design. Sadly, it's tradition (carried over from C) and we have to live with it. The find() method should throw an exception or return Integer and null if no item was found.
Developers forget to write code on every foo return because they assume that the value is pure, meaning that public List foo() will always return an empty list rather than a null value.
Yes, and that should always be the case, except if it's clear that the method can also return nothing, like in find(). public Integer find() can obviously return null if no value was found, for example. Other methods are search(), indexOf(), etc. Again, those methods should return null and not the idiomatic -1.
You are correct, Java's final is more like a const. Although I still don't see the point in avoiding null. Obviously you can't, so better to live with it and provide tools to detect a null pointer/reference, i.e. treat access to null like a bug. We already have div 0 bugs, overflow bugs, etc. and we have tools to detect them.
Yes, it can. Static code analyzers. But anyway, how does Option is suppose to work? Now every variable is by default Option.None and I have to sprinkle my code everywhere with foo.unwrap(default)? That's convenient (sarcasm). And what does the default should be? I don't have a default, that's the whole point! The value have no default, that's why it's null or Option.None in the first place. And we went full circle, and the only sensitive thing the app should do is either crash or show a big error message and exit. Btw, of course an app should gracefully shutdown, and that is possible even with null.
We already have that with static code analyzers. But how would you even do that with dynamic languages, where the type can just change at runtime? Furthermore, TypeScript is handling null just like Java. So the statement that "every mainstream programming language continues to support the null concept" is even more nonsensical, because TypeScript is one of those languages.// Compiled with --strictNullChecks let x: number; let y: number | null; let z: number | undefined; x;// Error, reference not preceded by assignment y;// Error, reference not preceded by assignment
every mainstream programming language continues to support the null concept.
Because you cannot do without. The computer cannot guess a value of a variable, so the default is always "Not Set" aka Null. Other languages use a Type.NULL or whatever, but it's just the same as Null. So, every language have a null concept.
There are also times when having the software crash is better than having it lie. That's what NULL is for.
Yes, please mod him +10. I'm sick and tired of people afraid of NPEs (NullPointerException, Java) or of null. A NPE means you have a bug in your code, and it's better for the app to crash than to corrupt your data, or silently just lose it.
- "Because it is not slow?" If a JS web site like the Kibana dashboard maxes out my CPU core (I have an Intel 5), how is it not slow? Compared to a native application that would use up max. 3% to 10% of my CPU.
- "You seem not to get it: some people like the language that is why they use it. And: if you want to have the same technology on frontend and backend it makes sense to use node.js on the backend." Use whatever you like. I'm discussing facts.
- "From a language designer standpoint it is a fine language, a few quirks, yes." No. From a language designer standpoint it's like the worst language out there, maybe worse than even PHP. Even Brainfuck is better. The need for === alone makes it the worst language.
- "Your arguments make no real sense in our times. JavaScript is now in its 6th reincarnation, it is extremely fast and much safer has less bugs etc." Citation needed. It still have the same bugs, and it's still very slow. Even the WebGL demos max out my CPU core. A native app would be around 1% of my CPU. The slowness is inherent to JS, I don't think the devs are incompetent.
- "Ofc there could be other scripting languages for browsers... but they never got traction and the ones we use in our days as alternatives are compiled to JavaScriot anyway." They never got traction because the W3C and the browsers devs are drinking the JS cool-aid. And because JS would die very fast if the browser devs would allow for any other language. For their benefit, they have their reasons of course. To have just one language for the Web is of course a benefit.
Again, the simpler solution would be to have a byte code standard, like the JVM have. Since the JS engines are all VMs anyway, it wouldn't be a problem. Another solution would be to fix JS, but that would brake a lot of web sites so that will never happen.
Yes, current alternative languages must compile to JS, so there is little or no benefit for using them. So it's no wonder they don't get any traction.
The demo (angry bots) still uses about 30% of my CPU resources. It doesn't lag because the graphic is all done by the GPU by OpenGL, but JS still sucks. On a phone it will drain the battery way faster than a native application.
Btw, I really don't get how devs are all in denial about the fact that JS is still slow as shit. Go to http://demo.elastic.co/ If I do anything on the graphs (like moving the mouse cursor over a graph), it's a noticeable lag in the UI, and my CPU goes up to 20% for Firefox. A native app (in any language) would be at 0-1% CPU and there would be no lag at all.
- "I doubt you know from your head a language that has prototype inheritance..." Again, it's not a good thing in and out itself. Other languages have other good features, it all depends how can I have my work done. I bet JavaScript can't access OpenGL, it needs to go through WebGL and other slow and cumbersome APIs. JavaScript put the web at least 10 years behind what it could have been. UI in JS are slow and unresponsive, that's in part the fault of JS itself. What do prototype inheritance me any good, if the JS code puts my CPU at 30% and makes my whole browser unresponsive. The browsers devs reacted by putting each tab into a new process. But again, that's just an attempt to fix the symptoms and not the decease. The W3C should have just released a byte code standard, and we could be free of JS (you could still use JS), and the browser devs could just concentrate on optimizing the byte code, instead of writing one slow JS parser after another.
- "The fact that you don't like the language does not make the language inferior." No, the bugs do. And that after 20 years of JS we still have slow and unresponsive UIs.
- "No idea what you mean with "automatic semicolon", in JavaScript semicolons are optional." You have really no clue about JS. The parser puts semicolons automatically into your code, that's the reasons why they are optional for you.
- "Of course it has... it just escapes you as you never tried it." That's a reply like from a religious person. "the love of God escapes you as you never tried it" - "You failed to name one... " Like every other language that is not JS. All languages have the same power, so obviously I was talking about them. - "The bugs of what?" ===, the automatic semicolon, "0" = true, and other bugs like the IEEE 754 standard. - "Nope... plenty of tools are written in JavaScript..." From 0.15% to 0.20% in a year. https://w3techs.com/technologi... Java (Tomcat), from 0.52% to 0.57% https://w3techs.com/technologi... So, there are way more Java tools written in a year than for Node.js.
- "JavaScript is the only class less, prototype based programming language in wide use." That's not really have any value in and out itself. - "So it is an extremely powerful language with arguable a bit painful syntax (to exploit those features)." There are many powerful languages with good syntax. - "90% of JavaScript just looks like C, so no idea why people hate it." Because of the many many bugs. - "OH!! You mean the integration in the browser? Yeah... never did any browser side JS, and likely never will." Browser integration is the only reason JS is popular.
Yes. See my argument above. Dtors cannot throw any exceptions, hence they are only useful for memory resources, i.e. resources that can't throw exceptions. For all the other resources, i.e. 99% of them, dtors are useless and RAII a serious design flaw.
Yes, and that's the problem. Then flush() will throw an exception because (for example) the disk was full, your program will just exit and the user's data are gone. In reality, you should write something like
ofstream myfile( "example.txt" );
myfile -- "Writing this to a file.\n";
ofstream flush();// catch exception, warn the user, maybe try a redo
ofstream close();// catch exception, warn the user
return 0;
Yes, good quote. But I go around that problem by just defining "truth" as that what conforms to reality. But, yes, you still need philosophy for "truth", even if it's just a small definition.
The Slashdot forum here is broken. ofstream myfile;
myfile.open ("example.txt");
myfile -- "Writing this to a file.\n";
myfile.close();
return 0; http://www.cplusplus.com/doc/t...
RAII is only useful for pointers. Dtors cannot throw any exceptions, that means that RAII is useless for anything else. See my post above. A GC is a more elegant solution for memory management.
For almost all kinds of problems, the fact that C++ destruction can automatically release resources, so you can safely return from anywhere in a function instead of having goto fail all over the place is a significant win for C++.
Too bad that that's not true. Dtors cannot throw exceptions, that means that dtors are only useful for releasing memory resources. Dtors are useless for releasing anything else, because all other resources can throw an exception upon release. For example, for the classical file stream example Dtors are useless.
I don't get your post. JNI was in Java since day one (or very early on), and via JNI you can access everything that is platform specific. MS or anyone else can just use JNI to bundle a Jar file for Java to allow access to DirectX and platform specific APIs. Java is not some magic, but it's basically a level above C/C++. The architecture is basically, Java>C>OS>Driver>Hardware. So, MS could have just bundled it's own Java+Windows specific modules.
And to put an browser in Java is also easy. https://www.teamdev.com/jxbrow... What difference does it make if it's the Chrome engine or some engine written in Java?
You have cherry picked one comment from Richard Stallman, which was just his personal ideology. David Edelsohn replied this: https://gcc.gnu.org/ml/gcc/201...
GCC is working toward re-factoring its code base toward a more compositional approach for "toolification". One can look at presentations from the recent GNU Cauldron 2013 for discussion of the topic. David Malcolm also has created patches for the GCC backend to be used as a JIT. The assertions that FSF policy prevents technical development and innovation simply is not true.
Maybe GCC was "deliberately obtuse", but as I see it, steps are taken to change that and enhance GCC for tool chains and to be used a library just as LVMM is.
"reverse a linked list in place," > use a double linked list. no need for any reversing. "balance a binary search tree," > use self-balancing binary search tree "find the missing number in an array" > disallow empty slots in the array, throw a runtime exception if the caller passed null into the array
Slashdot Mirror
Here is your unicorn https://en.wikipedia.org/wiki/...
I'm still not convinced that Option have any value. It looks more that it complicates development and is only here for null-phobic developers. But thank you for your time.
Java has checked exceptions. C# has unchecked exceptions. Option types are similar to Java's checked exceptions
How does Option helps in find(), search(), indexOf()? Why not just use exceptions or return null?
If a function can't return a meaningful value, it looks for me like a code smell. It should always return a meaningful value or throw an exception. The return of -1 in the find() method is a code smell and just bad design. Sadly, it's tradition (carried over from C) and we have to live with it. The find() method should throw an exception or return Integer and null if no item was found.
Developers forget to write code on every foo return because they assume that the value is pure, meaning that public List foo() will always return an empty list rather than a null value.
Yes, and that should always be the case, except if it's clear that the method can also return nothing, like in find(). public Integer find() can obviously return null if no value was found, for example. Other methods are search(), indexOf(), etc. Again, those methods should return null and not the idiomatic -1.
You are correct, Java's final is more like a const. Although I still don't see the point in avoiding null. Obviously you can't, so better to live with it and provide tools to detect a null pointer/reference, i.e. treat access to null like a bug. We already have div 0 bugs, overflow bugs, etc. and we have tools to detect them.
Yes, it can. Static code analyzers. But anyway, how does Option is suppose to work? Now every variable is by default Option.None and I have to sprinkle my code everywhere with foo.unwrap(default)? That's convenient (sarcasm). And what does the default should be? I don't have a default, that's the whole point! The value have no default, that's why it's null or Option.None in the first place. And we went full circle, and the only sensitive thing the app should do is either crash or show a big error message and exit. Btw, of course an app should gracefully shutdown, and that is possible even with null.
We already have that with static code analyzers. But how would you even do that with dynamic languages, where the type can just change at runtime? // Compiled with --strictNullChecks // Error, reference not preceded by assignment // Error, reference not preceded by assignment
Furthermore, TypeScript is handling null just like Java. So the statement that "every mainstream programming language continues to support the null concept" is even more nonsensical, because TypeScript is one of those languages.
let x: number;
let y: number | null;
let z: number | undefined;
x;
y;
That is just like Java's final keyword.
final int x;
every mainstream programming language continues to support the null concept.
Because you cannot do without. The computer cannot guess a value of a variable, so the default is always "Not Set" aka Null. Other languages use a Type.NULL or whatever, but it's just the same as Null. So, every language have a null concept.
It's just the same thing. Call it None or null, who cares.
There are also times when having the software crash is better than having it lie. That's what NULL is for.
Yes, please mod him +10. I'm sick and tired of people afraid of NPEs (NullPointerException, Java) or of null. A NPE means you have a bug in your code, and it's better for the app to crash than to corrupt your data, or silently just lose it.
- "Because it is not slow?"
If a JS web site like the Kibana dashboard maxes out my CPU core (I have an Intel 5), how is it not slow?
Compared to a native application that would use up max. 3% to 10% of my CPU.
- "You seem not to get it: some people like the language that is why they use it. And: if you want to have the same technology on frontend and backend it makes sense to use node.js on the backend."
Use whatever you like. I'm discussing facts.
- "From a language designer standpoint it is a fine language, a few quirks, yes."
No. From a language designer standpoint it's like the worst language out there, maybe worse than even PHP. Even Brainfuck is better.
The need for === alone makes it the worst language.
- "Your arguments make no real sense in our times. JavaScript is now in its 6th reincarnation, it is extremely fast and much safer has less bugs etc."
Citation needed. It still have the same bugs, and it's still very slow. Even the WebGL demos max out my CPU core. A native app would be around 1% of my CPU. The slowness is inherent to JS, I don't think the devs are incompetent.
- "Ofc there could be other scripting languages for browsers ... but they never got traction and the ones we use in our days as alternatives are compiled to JavaScriot anyway."
They never got traction because the W3C and the browsers devs are drinking the JS cool-aid. And because JS would die very fast if the browser devs would allow for any other language. For their benefit, they have their reasons of course. To have just one language for the Web is of course a benefit.
Again, the simpler solution would be to have a byte code standard, like the JVM have. Since the JS engines are all VMs anyway, it wouldn't be a problem. Another solution would be to fix JS, but that would brake a lot of web sites so that will never happen.
Yes, current alternative languages must compile to JS, so there is little or no benefit for using them. So it's no wonder they don't get any traction.
The demo (angry bots) still uses about 30% of my CPU resources. It doesn't lag because the graphic is all done by the GPU by OpenGL, but JS still sucks. On a phone it will drain the battery way faster than a native application.
Btw, I really don't get how devs are all in denial about the fact that JS is still slow as shit.
Go to http://demo.elastic.co/
If I do anything on the graphs (like moving the mouse cursor over a graph), it's a noticeable lag in the UI, and my CPU goes up to 20% for Firefox.
A native app (in any language) would be at 0-1% CPU and there would be no lag at all.
- "I doubt you know from your head a language that has prototype inheritance ..."
Again, it's not a good thing in and out itself. Other languages have other good features, it all depends how can I have my work done.
I bet JavaScript can't access OpenGL, it needs to go through WebGL and other slow and cumbersome APIs.
JavaScript put the web at least 10 years behind what it could have been. UI in JS are slow and unresponsive, that's in part the fault of JS itself.
What do prototype inheritance me any good, if the JS code puts my CPU at 30% and makes my whole browser unresponsive.
The browsers devs reacted by putting each tab into a new process. But again, that's just an attempt to fix the symptoms and not the decease.
The W3C should have just released a byte code standard, and we could be free of JS (you could still use JS), and the browser devs could just concentrate on optimizing the byte code, instead of writing one slow JS parser after another.
- "The fact that you don't like the language does not make the language inferior."
No, the bugs do. And that after 20 years of JS we still have slow and unresponsive UIs.
- "No idea what you mean with "automatic semicolon", in JavaScript semicolons are optional."
You have really no clue about JS. The parser puts semicolons automatically into your code, that's the reasons why they are optional for you.
- "Of course it has ... it just escapes you as you never tried it." ... " ... plenty of tools are written in JavaScript ..."
That's a reply like from a religious person. "the love of God escapes you as you never tried it"
- "You failed to name one
Like every other language that is not JS.
All languages have the same power, so obviously I was talking about them.
- "The bugs of what?"
===, the automatic semicolon, "0" = true, and other bugs like the IEEE 754 standard.
- "Nope
From 0.15% to 0.20% in a year.
https://w3techs.com/technologi...
Java (Tomcat), from 0.52% to 0.57%
https://w3techs.com/technologi...
So, there are way more Java tools written in a year than for Node.js.
- "JavaScript is the only class less, prototype based programming language in wide use." ... never did any browser side JS, and likely never will."
That's not really have any value in and out itself.
- "So it is an extremely powerful language with arguable a bit painful syntax (to exploit those features)."
There are many powerful languages with good syntax.
- "90% of JavaScript just looks like C, so no idea why people hate it."
Because of the many many bugs.
- "OH!! You mean the integration in the browser? Yeah
Browser integration is the only reason JS is popular.
Dafuq? Are you serious?
Yes. See my argument above. Dtors cannot throw any exceptions, hence they are only useful for memory resources, i.e. resources that can't throw exceptions. For all the other resources, i.e. 99% of them, dtors are useless and RAII a serious design flaw.
Yes, and that's the problem. Then flush() will throw an exception because (for example) the disk was full, your program will just exit and the user's data are gone. In reality, you should write something like
ofstream myfile( "example.txt" ); // catch exception, warn the user, maybe try a redo // catch exception, warn the user
myfile -- "Writing this to a file.\n";
ofstream flush();
ofstream close();
return 0;
Yes, good quote. But I go around that problem by just defining "truth" as that what conforms to reality. But, yes, you still need philosophy for "truth", even if it's just a small definition.
The Slashdot forum here is broken.
ofstream myfile;
myfile.open ("example.txt");
myfile -- "Writing this to a file.\n";
myfile.close();
return 0;
http://www.cplusplus.com/doc/t...
RAII is only useful for pointers. Dtors cannot throw any exceptions, that means that RAII is useless for anything else. See my post above. A GC is a more elegant solution for memory management.
For almost all kinds of problems, the fact that C++ destruction can automatically release resources, so you can safely return from anywhere in a function instead of having goto fail all over the place is a significant win for C++.
Too bad that that's not true. Dtors cannot throw exceptions, that means that dtors are only useful for releasing memory resources.
Dtors are useless for releasing anything else, because all other resources can throw an exception upon release.
For example, for the classical file stream example Dtors are useless.
ofstream myfile;
myfile.open ("example.txt");
myfile
You see that the ofstream have a method close() and is not using the Dtors of C++. That's because see my point above.
I don't get your post. JNI was in Java since day one (or very early on), and via JNI you can access everything that is platform specific. MS or anyone else can just use JNI to bundle a Jar file for Java to allow access to DirectX and platform specific APIs. Java is not some magic, but it's basically a level above C/C++. The architecture is basically, Java>C>OS>Driver>Hardware. So, MS could have just bundled it's own Java+Windows specific modules.
And to put an browser in Java is also easy. https://www.teamdev.com/jxbrow...
What difference does it make if it's the Chrome engine or some engine written in Java?
You have cherry picked one comment from Richard Stallman, which was just his personal ideology. David Edelsohn replied this:
https://gcc.gnu.org/ml/gcc/201...
GCC is working toward re-factoring its code base toward a more
compositional approach for "toolification". One can look at
presentations from the recent GNU Cauldron 2013 for discussion of the
topic. David Malcolm also has created patches for the GCC backend to be used as a JIT.
The assertions that FSF policy prevents technical development and
innovation simply is not true.
Maybe GCC was "deliberately obtuse", but as I see it, steps are taken to change that and enhance GCC for tool chains and to be used a library just as LVMM is.
"reverse a linked list in place,"
> use a double linked list. no need for any reversing.
"balance a binary search tree,"
> use self-balancing binary search tree
"find the missing number in an array"
> disallow empty slots in the array, throw a runtime exception if the caller passed null into the array