Why is the Federal Government getting involved in elections for the first time in all of US history? I know I have a good guess as to why.
Because, for the first time in US history, there's strong evidence that foreign governments are interfering with elections?
For that matter, I don't see why the notion of federal government getting involved in elections that select people who run said federal government to be unusual or worrisome. There are a bunch of constitutional requirements and laws pertaining to elections on the federal level - who should enforce them, if not the feds?
You'd be looking at a complete paradigm shift when it comes to economies. That is to say, not communism, not capitalism, nor any other economic system of the past.
Actually, it would be an economic system described in the past, just never actually implemented - namely, communism. To remind, USSR and other "communist" countries never actually claimed to be communist. They said that they were socialist (debatable), and were progressing on the way to communism (ha!). The latter never happened, but as a hypothetical economic system, it's basically what you naturally get once you're post-scarcity or close to it for living essentials. Which is exactly where we're heading with automation. Marxism was all about how you couldn't ever get to communism without socialism, but that theory did not survive practical testing.
It's actually quite likely to happen, precisely because it has proponents on both left and right. Left is self-explanatory, but on the right, there are many people who recognize that some form of welfare is necessary, but want to keep it as low-overhead in terms of government bureaucracy as possible. UBI does just that.
Code is text, not binary. Get the binary out of the code.
That makes no sense at all. Do you also avoid LF? It's just as "binary" as TAB is.
I shouldn't have to mess with my editor to get sane spacing.
Any sane code editor comes preconfigured for sane spacing, whether it uses tabs or spaces. If it doesn't, you probably have to configure it for space-based indentation the way you want anyway, so you might as well change the tab size to the same amount, too.
if you really need to see it with some OTHER number of spaces than are actually there, I bet there's a text transform you could apply to the spaced file too.
Not really. Well, it depends on the coding style. If you only ever use full-size indents for everything, and never e.g. align function arguments or struct members, then yes, you can transform like so - just grab the leading whitespace on every line and replace it.
But if your coding style is to line things up beyond indent levels - which is the convention for some languages like, say, Haskell - then you have two semantically different kinds of whitespace - indentation proper, and then extra whitespace to line things up. If you use all spaces (or all tabs) for both, that distinction is lost in code, and there isn't really any reliable way to recover it by parsing that code. On the other hand, if you use tabs for indentation, and spaces to line things up, then changing the tab size will change indentation without affecting alignment.
Note that this requires a fairly disciplined approach - you can only use tabs at the beginning of the line, and you have to be careful to never ever use them to align things beyond nested blocks and such. So, for example, if you write something like:
struct foo {
int bar,
baz; };
for "int bar", you use a single tab to indent. But for "baz", you must not use two tabs, even if that gives the desired alignment at your tab settings. You must use one tab, same as the previous line and all other lines inside the same block, and then the requisite amount of spaces to line things up. Then, even if tab size changes, those spaces will still make sure that "bar" and "baz" appear exactly under each other.
So this scheme works and doesn't have any issues that you have listed. However, it does add mental overhead for the person writing the code. Whether it's worth it or not is a subjective decision of the person (or the team).
The scheme that he described doesn't require this. Code will look properly lined up for any tab size from 1 to infinity. The only problem is that if you develop with 4-space tabs, say, and then open it in an editor configured for 8-space tabs, that extra indentation will cause the lines to be longer than they otherwise were. But you don't need to know how many spaces he used when writing the code - you configure it with your own preferences for tab-size, that are probably less than the default 8 spaces.
The level of indentation is plainly visible, but it looks the same (unless you're using an editor that specially marks tabs somehow) whether you're using spaces or tabs. Therefore, the tab characters are effectively invisible.
Python prohibits mixing spaces and tabs for indentation. So while you don't know whether that indent is using spaces or tabs, what you do know is that all indents that look the same in the same file have the same meaning.
You don't need arbitrary precision for the task that OP asked about. And, indeed, numerous languages that catered to that niche before managed just fine with either fixed-precision or floating-point fixed-size decimal data types - Currency in VB and Delphi, Decimal in C# etc.
So what you're saying is that BigDecimal is overkill for this job, and inconvenient to use for that reason.
Then again, we weren't talking about BigDecimal here, either. If you walk up the thread, you'll see that it was about "JSR 354: Money and Currency API". Which is exactly the kind of thing that lets you say A*B - or rather A.multiply(B) - with all the details coming implicitly from context. Which, coincidentally, is provided with sane settings (i.e. the kind that accountants normally use) by default.
Lambda notation has no place in an imperative language; mixing paradigms is confusing for the vast majority of Java programmers
Really? Common Lisp had it for 30 years now.
And lambdas do not necessarily correspond to a "functional" paradigm. For that matter, paradigms themselves are blurry - they are a rather arbitrary, and very coarse, human classification of much more complicated patterns. If you have ever passed a function pointer to another function in C, one could argue that you're "mixing paradigms".
The Optional class. Instead of checking directly for a null result, you have to unpack every result out of this idiotic wrapper.
It's a good thing, because it forces you to check when you use, while allowing pass-through to be zero-overhead.
Null pointer, which you have to check, but can use without checking, is a flawed concept in that regard due to decoupling of these two operations - which is why NRE or equivalent is one of the most common unintended exception type in Java (and other languages that share the concept, which is most mainstream ones). Even the guy who invented the concept 50 years ago considers it his worst mistake.
What Java could use is a better syntax for making those checks/uses - some kind of syntactic sugar that's more concise than lambdas. Something like "match" from ML would be nice, but probably too unfamiliar to most Java users. Kotlin does the next best thing by making regular null comparisons change the type of the compared variable within one of the branches, i.e.:
var x: String?;// ? means nullable y = x.length;// won't compile, since String? can be null, and member access is not valid on null. ... if (x != null) { // x is of type String inside here, cannot be null
y = x.length;// compiles, no NRE possible here } ... y = x.length;// still illegal ...
which is really the same thing, but wrapped in a way that's more familiar to someone coming from a C-style language.
On the contrary, with better lambdas, Java wouldn't need OOP, since lambdas give you state + identity + encapsulation in a much simpler abstraction than classes.
Think of Optional as a collection that has either one or zero elements. Then it all makes much more sense.
But what he was really trying to show is that you can treat optionals as a monad, same way as in e.g. Haskell. Although not quite, because in Haskell you get some nice syntactic sugar that makes it all much smoother.
Accountants want decimal, because input numbers are going to be represented as decimal, even before you start doing any operations on them. And binary floating-point may not be able to represent those inputs accurately, while decimal floating-point will.
Operator overloading per se is not good or bad. Or rather it's inherently good, because it lets you implement various number-like data types as libraries, and there's no way any language is going to implement everything that someone might need in the base language itself (think rational numbers, complex numbers and quaternions, ranges, sets, vectors and matrices etc).
What can be bad is a particular use of operator overloading where it's not supposed to be used. This is not specific to operators - method overloading can be similarly misused, as can inheritance and many other features.
C++ iostreams are an unquestionable example of bad design in that regard, but it's rather telling that this example, which dates back to, what, late 1980s, is still the one cited - because there aren't really any other examples of prominence. C# also has operator overloading, for example, and that makes it possible to define Decimal, Complex etc as library types - but it doesn't use it for streams (or any other weird stuff where the behavior is non-obvious).
.NET had "decimal" since the very first release in 2001. The actual type predates.NET even - Decimal in VB6 is the same exact thing, and it corresponded to DECIMAL structure (and the corresponding VT_DECIMAL variant subtype) in OLE Automation, which is still usable from regular Win32 apps. If I remember correctly, that, in turn, was an implementation of some early IEEE spec for decimal floating point.
Without operator overloading in the language, any attempt to implement something like this as a library is going to be subpar: x.add(y).multiply(z) etc - you might as well be coding in COBOL.
Streams took easy to read and understand for loops used by every language on earth and replaced it with gibberish that you need to work through to understand
If you have been writing simple maps and folds as explicit for-loops for 20 years, I can see that being a problem. But for someone whose mind is not so conditioned, streams are clearer because they describe what is done, not how it's done - and more concise at that.
is far more difficult top debug as there's no damn place to put a break point or print statement.
You can put it inside the lambda, you know. Which is exactly equivalent to putting it inside the for-loop body.
They're banned everywhere I've heard of
Yeah, we passed that stage in C# land, too, after they've added lambdas and LINQ back in 2008. Took about 3-4 years for the old guard to give up and embrace the future.
Every other tech that is somehow competing has server drawbacks. I don't see anyone doing enterprise software in Python, C++ or C#/.Net...
If you don't see anyone doing enterprise software in C++ or C#, you haven't looked hard enough. There are thousands of companies doing exactly that. Heck, go check out any job search site.
One particular trap that you may be falling into is assuming that your local market is representative of other places. Some geographic regions can become locally locked in to some tech that dominates the market in that region - Java, Delphi, VB, you name it. These come and go, though, and of course, being local, they don't necessarily correspond to the bigger trend.
An no other 'ecosystem' is as dynamic and moving quickly as Java is
I have no idea what your definitions of "dynamic" and "moving quickly" are, except that they clearly aren't mainstream.
In terms of moving quickly, Java is the laughing stock - they took several years to implement lambdas, for example, and they were overtaken even by C++ in the process, being pretty much the last mainstream language to get them. Even then, the result is a crapshoot due to the lack of reified generics, requiring tons of interface definitions to cover a very basic subset of functions taking/returning primitive values while avoiding boxing and the associated perf issues.
In terms of dynamic, obviously, Java can't really compete with a true dynamic language like Python. But even C# leaves it far behind in that regard, with opt-in duck typing.
thanx to ByteCode and ByteCode morphing technologies.
Bytecode is an implementation technique predating Java by 30 years or so, and is used by most VMs out there. Including C# and Python. C# ramps it up a notch by providing AST-like expression trees as a first-class data type, which can be inspected and changed at runtime before they get compiled to bytecode.
Stuff like Annotation processing, Byte Code Weaving, Hibernate, AspectJ etc. simply don't exist in such abundance outside of the JVM ecosystem.
Every single thing that you've listed exists in other ecosystems. In some cases it's direct ports of the same projects even. As for abundance, who needs that in the enterprise? What people want is a single stable implementation that everyone can standardize on.
Standards, like servlets etc. only Java has that.
Care to list a single ISO or ANSI standard that defines Java language or VM?
C++, for example, is standardized by ISO, both the language and the standard library. An older version of C# the language (sans standard library) is also an ISO standard.
And who uses servlets in 2016, anyway?
People who don't grassp that Java (the platform) is the most solid and most flexible and most avangard platform for anything around software, simply should not work in the software business.
People who don't grasp that creating a religious cult around a piece of software is a bad idea shouldn't work in the software business.
In what sense is C# the language designed for Windows environments?
The original.NET standard library (what's now known as "desktop profile"), you could say that in places (though not for 90% of it - a linked list is a linked list on any platform, for example). But the new.NET Core is designed to be cross-platform from the very beginning.
Do you still have to use that horrible Mono implementation on Linux?
You don't. However,.NET Core has a more limited standard library - in particular, it doesn't include anything GUI-wise out of the box. I would imagine that existing libraries like Gtk# will be ported to it soon enough, but from Microsoft's perspective, its primary purpose is to run server-side code - web apps and services - and various associated command-line infrastructure tooling.
Slashdot Mirror
Why is the Federal Government getting involved in elections for the first time in all of US history? I know I have a good guess as to why.
Because, for the first time in US history, there's strong evidence that foreign governments are interfering with elections?
For that matter, I don't see why the notion of federal government getting involved in elections that select people who run said federal government to be unusual or worrisome. There are a bunch of constitutional requirements and laws pertaining to elections on the federal level - who should enforce them, if not the feds?
You'd be looking at a complete paradigm shift when it comes to economies. That is to say, not communism, not capitalism, nor any other economic system of the past.
Actually, it would be an economic system described in the past, just never actually implemented - namely, communism. To remind, USSR and other "communist" countries never actually claimed to be communist. They said that they were socialist (debatable), and were progressing on the way to communism (ha!). The latter never happened, but as a hypothetical economic system, it's basically what you naturally get once you're post-scarcity or close to it for living essentials. Which is exactly where we're heading with automation. Marxism was all about how you couldn't ever get to communism without socialism, but that theory did not survive practical testing.
It's actually quite likely to happen, precisely because it has proponents on both left and right. Left is self-explanatory, but on the right, there are many people who recognize that some form of welfare is necessary, but want to keep it as low-overhead in terms of government bureaucracy as possible. UBI does just that.
They allow either, so long as they aren't mixed.
Code is text, not binary. Get the binary out of the code.
That makes no sense at all. Do you also avoid LF? It's just as "binary" as TAB is.
I shouldn't have to mess with my editor to get sane spacing.
Any sane code editor comes preconfigured for sane spacing, whether it uses tabs or spaces. If it doesn't, you probably have to configure it for space-based indentation the way you want anyway, so you might as well change the tab size to the same amount, too.
if you really need to see it with some OTHER number of spaces than are actually there, I bet there's a text transform you could apply to the spaced file too.
Not really. Well, it depends on the coding style. If you only ever use full-size indents for everything, and never e.g. align function arguments or struct members, then yes, you can transform like so - just grab the leading whitespace on every line and replace it.
But if your coding style is to line things up beyond indent levels - which is the convention for some languages like, say, Haskell - then you have two semantically different kinds of whitespace - indentation proper, and then extra whitespace to line things up. If you use all spaces (or all tabs) for both, that distinction is lost in code, and there isn't really any reliable way to recover it by parsing that code. On the other hand, if you use tabs for indentation, and spaces to line things up, then changing the tab size will change indentation without affecting alignment.
Note that this requires a fairly disciplined approach - you can only use tabs at the beginning of the line, and you have to be careful to never ever use them to align things beyond nested blocks and such. So, for example, if you write something like:
for "int bar", you use a single tab to indent. But for "baz", you must not use two tabs, even if that gives the desired alignment at your tab settings. You must use one tab, same as the previous line and all other lines inside the same block, and then the requisite amount of spaces to line things up. Then, even if tab size changes, those spaces will still make sure that "bar" and "baz" appear exactly under each other.
So this scheme works and doesn't have any issues that you have listed. However, it does add mental overhead for the person writing the code. Whether it's worth it or not is a subjective decision of the person (or the team).
The scheme that he described doesn't require this. Code will look properly lined up for any tab size from 1 to infinity. The only problem is that if you develop with 4-space tabs, say, and then open it in an editor configured for 8-space tabs, that extra indentation will cause the lines to be longer than they otherwise were. But you don't need to know how many spaces he used when writing the code - you configure it with your own preferences for tab-size, that are probably less than the default 8 spaces.
The level of indentation is plainly visible, but it looks the same (unless you're using an editor that specially marks tabs somehow) whether you're using spaces or tabs. Therefore, the tab characters are effectively invisible.
Python prohibits mixing spaces and tabs for indentation. So while you don't know whether that indent is using spaces or tabs, what you do know is that all indents that look the same in the same file have the same meaning.
In Python 3, you cannot mix tabs and spaces like that - it's specifically forbidden, and will result in a syntax error.
There is one mixing scheme that does not have this problem. Namely:
- use tabs for indentation only
- use spaces to align everything else (after indenting with tabs)
This way, changing tab size only affects indent level, but other things will remain lined up.
In practice, though, it's still not worth the bother. Spaces all around is easier.
C# doesn't have much of an existence outside Microsoft's area of influence, so your statement applies more to you than any one else.
Microsoft's "area of influence" is global, so this isn't really telling anything.
But note that I didn't claim that C# is the only popular, or even the most popular, server-side enterprise language.
You were saying?
You don't need arbitrary precision for the task that OP asked about. And, indeed, numerous languages that catered to that niche before managed just fine with either fixed-precision or floating-point fixed-size decimal data types - Currency in VB and Delphi, Decimal in C# etc.
So what you're saying is that BigDecimal is overkill for this job, and inconvenient to use for that reason.
Then again, we weren't talking about BigDecimal here, either. If you walk up the thread, you'll see that it was about "JSR 354: Money and Currency API". Which is exactly the kind of thing that lets you say A*B - or rather A.multiply(B) - with all the details coming implicitly from context. Which, coincidentally, is provided with sane settings (i.e. the kind that accountants normally use) by default.
Lambda notation has no place in an imperative language; mixing paradigms is confusing for the vast majority of Java programmers
Really? Common Lisp had it for 30 years now.
And lambdas do not necessarily correspond to a "functional" paradigm. For that matter, paradigms themselves are blurry - they are a rather arbitrary, and very coarse, human classification of much more complicated patterns. If you have ever passed a function pointer to another function in C, one could argue that you're "mixing paradigms".
The Optional class. Instead of checking directly for a null result, you have to unpack every result out of this idiotic wrapper.
It's a good thing, because it forces you to check when you use, while allowing pass-through to be zero-overhead.
Null pointer, which you have to check, but can use without checking, is a flawed concept in that regard due to decoupling of these two operations - which is why NRE or equivalent is one of the most common unintended exception type in Java (and other languages that share the concept, which is most mainstream ones). Even the guy who invented the concept 50 years ago considers it his worst mistake.
What Java could use is a better syntax for making those checks/uses - some kind of syntactic sugar that's more concise than lambdas. Something like "match" from ML would be nice, but probably too unfamiliar to most Java users. Kotlin does the next best thing by making regular null comparisons change the type of the compared variable within one of the branches, i.e.:
which is really the same thing, but wrapped in a way that's more familiar to someone coming from a C-style language.
On the contrary, with better lambdas, Java wouldn't need OOP, since lambdas give you state + identity + encapsulation in a much simpler abstraction than classes.
Think of Optional as a collection that has either one or zero elements. Then it all makes much more sense.
But what he was really trying to show is that you can treat optionals as a monad, same way as in e.g. Haskell. Although not quite, because in Haskell you get some nice syntactic sugar that makes it all much smoother.
Give it tuples or other form of multiple return values, and forget about pass-by-reference.
Accountants want decimal, because input numbers are going to be represented as decimal, even before you start doing any operations on them. And binary floating-point may not be able to represent those inputs accurately, while decimal floating-point will.
Operator overloading per se is not good or bad. Or rather it's inherently good, because it lets you implement various number-like data types as libraries, and there's no way any language is going to implement everything that someone might need in the base language itself (think rational numbers, complex numbers and quaternions, ranges, sets, vectors and matrices etc).
What can be bad is a particular use of operator overloading where it's not supposed to be used. This is not specific to operators - method overloading can be similarly misused, as can inheritance and many other features.
C++ iostreams are an unquestionable example of bad design in that regard, but it's rather telling that this example, which dates back to, what, late 1980s, is still the one cited - because there aren't really any other examples of prominence. C# also has operator overloading, for example, and that makes it possible to define Decimal, Complex etc as library types - but it doesn't use it for streams (or any other weird stuff where the behavior is non-obvious).
.NET had "decimal" since the very first release in 2001. The actual type predates .NET even - Decimal in VB6 is the same exact thing, and it corresponded to DECIMAL structure (and the corresponding VT_DECIMAL variant subtype) in OLE Automation, which is still usable from regular Win32 apps. If I remember correctly, that, in turn, was an implementation of some early IEEE spec for decimal floating point.
Without operator overloading in the language, any attempt to implement something like this as a library is going to be subpar: x.add(y).multiply(z) etc - you might as well be coding in COBOL.
Streams took easy to read and understand for loops used by every language on earth and replaced it with gibberish that you need to work through to understand
If you have been writing simple maps and folds as explicit for-loops for 20 years, I can see that being a problem. But for someone whose mind is not so conditioned, streams are clearer because they describe what is done, not how it's done - and more concise at that.
is far more difficult top debug as there's no damn place to put a break point or print statement.
You can put it inside the lambda, you know. Which is exactly equivalent to putting it inside the for-loop body.
They're banned everywhere I've heard of
Yeah, we passed that stage in C# land, too, after they've added lambdas and LINQ back in 2008. Took about 3-4 years for the old guard to give up and embrace the future.
Every other tech that is somehow competing has server drawbacks. I don't see anyone doing enterprise software in Python, C++ or C#/.Net ...
If you don't see anyone doing enterprise software in C++ or C#, you haven't looked hard enough. There are thousands of companies doing exactly that. Heck, go check out any job search site.
One particular trap that you may be falling into is assuming that your local market is representative of other places. Some geographic regions can become locally locked in to some tech that dominates the market in that region - Java, Delphi, VB, you name it. These come and go, though, and of course, being local, they don't necessarily correspond to the bigger trend.
An no other 'ecosystem' is as dynamic and moving quickly as Java is
I have no idea what your definitions of "dynamic" and "moving quickly" are, except that they clearly aren't mainstream.
In terms of moving quickly, Java is the laughing stock - they took several years to implement lambdas, for example, and they were overtaken even by C++ in the process, being pretty much the last mainstream language to get them. Even then, the result is a crapshoot due to the lack of reified generics, requiring tons of interface definitions to cover a very basic subset of functions taking/returning primitive values while avoiding boxing and the associated perf issues.
In terms of dynamic, obviously, Java can't really compete with a true dynamic language like Python. But even C# leaves it far behind in that regard, with opt-in duck typing.
thanx to ByteCode and ByteCode morphing technologies.
Bytecode is an implementation technique predating Java by 30 years or so, and is used by most VMs out there. Including C# and Python. C# ramps it up a notch by providing AST-like expression trees as a first-class data type, which can be inspected and changed at runtime before they get compiled to bytecode.
Stuff like Annotation processing, Byte Code Weaving, Hibernate, AspectJ etc. simply don't exist in such abundance outside of the JVM ecosystem.
Every single thing that you've listed exists in other ecosystems. In some cases it's direct ports of the same projects even. As for abundance, who needs that in the enterprise? What people want is a single stable implementation that everyone can standardize on.
Standards, like servlets etc. only Java has that.
Care to list a single ISO or ANSI standard that defines Java language or VM?
C++, for example, is standardized by ISO, both the language and the standard library. An older version of C# the language (sans standard library) is also an ISO standard.
And who uses servlets in 2016, anyway?
People who don't grassp that Java (the platform) is the most solid and most flexible and most avangard platform for anything around software, simply should not work in the software business.
People who don't grasp that creating a religious cult around a piece of software is a bad idea shouldn't work in the software business.
In what sense is C# the language designed for Windows environments?
The original .NET standard library (what's now known as "desktop profile"), you could say that in places (though not for 90% of it - a linked list is a linked list on any platform, for example). But the new .NET Core is designed to be cross-platform from the very beginning.
Do you still have to use that horrible Mono implementation on Linux?
You don't. However, .NET Core has a more limited standard library - in particular, it doesn't include anything GUI-wise out of the box. I would imagine that existing libraries like Gtk# will be ported to it soon enough, but from Microsoft's perspective, its primary purpose is to run server-side code - web apps and services - and various associated command-line infrastructure tooling.
I don't know C#, other than it is a sort of almost C++, but not quite.
This would imply that you don't know it at all.
C# was sort of almost Java, except with a bunch of different syntax of C++ and Delphi heritage. But that was back in 2001.
These days, it's still closer to Java than it is to C++, but I'd say it's pretty far ahead of Java in terms of high-level language features.