-
journeysquid
3 years ago
|
link
| on:
Introducing gngr: a new browser under development, focussed on privacy
For alternatives that are available today, consider xombrero: https://opensource.conformal.com/wiki/xombrero
-
-
This seems like a win for everyone involved!
… except for the person who doesn’t have time to absorb the project style guide, learn the community, navigate any legal sign-offs, and send a patch because they are buying a house, raising a child, dealing with a sick family member, or because they just plain don’t like to program outside work.
I’ve never liked open-source driven hiring. It seems to lead to monocultures (look around and count how many people aren’t twenty something white guys) and a lack of focus on training and career development (they don’t have to pay if you do it for free, right?).
-
For the purpose of hiring, style-guides, learning the community and contributor agreements don’t matter. The recruiter can judge the quality of the effort irrespective of all that.
Making a patch is very easy these days, with tools and workflows like git.
Finally, if they are busy and can’t contribute to open-source, the candidates can simply say so. I am sure exceptions can be made by the recruiter.
-
For the purpose of hiring, style-guides, learning the community and contributor agreements don’t matter. The recruiter can judge the quality of the effort irrespective of all that.
I mean at that point you’ve set up a typical code challenge - I doubt most open source projects are going to use a patch that comes through without adhering to licensing/style/etc., so you’re just having candidates write throwaway code. Again.
It’s probably harder to judge as well, because you can’t rely on the external judge (the maintainer) to provide any valuable input.
Finally, if they are busy and can’t contribute to open-source, the candidates can simply say so. I am sure exceptions can be made by the recruiter.
Who’d you hire - the person whose git checkins show that they’re up at 2 AM poking at code, or the person that signals “I have better things to do than work on your shit 24/7”? Most companies will pick #1, and frankly that’s a rational approach. But that also means you end up with people who are young, healthy, and with few external commitments. A monoculture.
-
Most companies will pick #1, and frankly that’s a rational approach. But that also means you end up with people who are young, healthy, and with few external commitments. A monoculture.
So this raises the obvious question: are there other ways to gauge the skill of a candidate that avoid this problem without being ridiculously expensive or significantly less accurate?
-
So this raises the obvious question: are there other ways to gauge the skill of a candidate that avoid this problem without being ridiculously expensive or significantly less accurate?
None that I know of. That’s why it’s so damn ugly.
If someone could figure out how to effectively hire programmers I think they’d make a mint.
-
-
I mean at that point you’ve set up a typical code challenge - I doubt most open source projects are going to use a patch that comes through without adhering to licensing/style/etc., so you’re just having candidates write throwaway code. Again.
No, the patch may be later refined by anyone; including the maintainer or the recruiter or the candidate. About licensing, it just takes an online form or similar to assign a copyright.
Even if the code were to be thrown away, what’s there to lose? Isn’t it better than the prospect of deliberating writing throw-away code?
Who’d you hire - the person whose git checkins show that they’re up at 2 AM poking at code, or the person that signals “I have better things to do than work on your shit 24/7”?
How does the time of coding matter at all? A person may be in another time-zone. Or could be doing “better” things in the evening while coding in the night. Or may just prefer a time that allows them to be in the zone.
Moreover, decisions related to culture can be made independently of those about ability. In fact, most of the interview score sheets I have seen have been designed that way.
-
How does the time of coding matter at all?
You’re focusing on the “up at 2AM part”. The part I wanted to stress was that a company is more likely to hire someone who jumps through the hoops than someone that doesn’t.
Moreover, decisions related to culture can be made independently of those about ability. In fact, most of the interview score sheets I have seen have been designed that way.
I’m interested to see how companies handle issues of culture. Most seem to do it rather poorly.
The main point I’m trying to make here: open source developers are overwhelmingly twenty something white males with free time; if you use open source to hire, that’s the kind of person you’re likely to get.
-
-
-
-
-
This is nice, though a more general extension is HTTP SwitchBoard. You can enable / disable lots of things apart from images, such as cookies, scripts, frames, etc. Though you won’t have the convenience of a keyboard shortcut to quickly toggle them on or off.
-
journeysquid
4 years ago
|
link
| on:
22% of users would run an arbitrary executable on their machines for a small amount of cash
You don’t even need cash, just tell tell them to pipe wget to a shell and they’ll do it blindly. With sudo.
-
It’s amazing how even technically-minded people are willing to do things like copy, paste, and run an arbitrary line of code from a website. A person searches for a solution to some issue they’re having, and will often just blindly use whatever code is handed to them as the answer. I’d be curious to see how hard it would be to trick people into pasting and running something malicious.
-
Leave aside pipe and wget, a simple copy-paste is sufficient.
-
-
-
There are open-source projects that have bounties. These projects are more likely to accept contributions, and you are also likely to get a monetary reward for your work.
A site that I know and lists such bounties is Freedom Sponsors
-
peter
4 years ago
|
link
| on:
Java is the COBOL of my generation and Go is its successor (and other reflections after GopherCon)
Does this mean that ultimately, many of us will be bitter about how lousy Go is, and wish for something better? That’s a bummer, Go is really quite nice. But it’s awesome because eventually, there will be something so fabulous it makes Go look like garbage. :D
Also regarding Go and generics, I see the usefulness/complexity thing cited everywhere, but how does Go as a language help avoid needing generics? Slices, maps, and channels are generic, is that really all you need to do things?
-
But it’s awesome because eventually, there will be something so fabulous it makes Go look like garbage. :D
I’ve already seen many things which make it look like that.
Slices, maps, and channels are generic, is that really all you need to do things?
No, and so Go requires you to lie to the type system (i.e. cast) when you want to do things generically.
-
-
- Haskell
- ML
- Scala
- Java
- Rust
- Java
- F#
- C#
- C++
The above are much more capable of writing reusable functions. Some are again much more capable than the others, but the bar is pretty low!
-
Whining about a language is a waste of everyone’s time. If you have something useful to contribute, do so. Plenty of people have given detailed, reasoned, substantial accounts of their experiences with Go, good and bad. Maybe it wasn’t clear, but that sort of answer is the kind I was inviting.
-
Criticising things is an important thing to do. Being smug about something is not useful.
-
Criticising things is an important thing to do.
I’d argue that constructively criticizing things is an important thing to do. If criticism isn’t constructive, then you have little hope of the right people reconsidering what they think they know.
Your comments in this thread are certainly not constructive.
-
-
-
-
-
-
No, and so Go requires you to lie to the type system (i.e. cast) when you want to do things generically.
Go supports a different form of compile time safe polymorphism via structural sub-typing. No lying necessary.
-
I agree that Go supports a single, limited form of polymorphism. Very quickly you come to a point where you have to lie.
-
In what situations? When you are writing your own generic containers you run into a problem, but otherwise when you you actually need more than an interface? The built in containers are quite capable for most applications. If you truly need a specific data structure, how often are you going to need to use it on any possible type? A database may use a skip list for good concurrency working with tuples. A text editor may use a rope for working with strings. I would argue that using those specialized data structures generically in every situation is marginally useful.
The Go developers argue that generics are not adequately useful to be added, and I haven’t seen a compelling example that indicates otherwise, do you have one?
-
The built in containers are quite capable for most applications. If you truly need a specific data structure, how often are you going to need to use it on any possible type?
I want a Tree data structure, maybe I’ll only use it on 3 different types of values in my application but why:
- Should I have to write it myself rather than rely on a library?
- Should I have to either write it 3 different times or give up type safety by casting?
- Should I know about what’s in the Tree when I don’t need to?
The 3rd point might not seem like a problem but it has huge implications, documented in a concept called parametricity.
I would argue that using those specialized data structures generically in every situation is marginally useful.
It’s not just data structures. Functions shouldn’t have to be unnecessarily specialised. If I need to write a function like so:
func idInt(a int) int { return a }Why should we care about whether it’s an int or a string or a gobbledok? Our alternative is to use an interface:
func id(a interface {}) interface {} { return a }But now we know nothing about the output type when we go to use it. We’d have to cast - will that work? Only after knowing exactly the definition of the function do we know for sure.
I hope I don’t have high standards by refusing to use a system which doesn’t allow using types as documentation or which asks for information it doesn’t need nor use.
-
I am familiar with all of the concepts you described. However, Go emphasizes simplicity. I haven’t ever heard someone claim that they encountered a serious problem with lack of total parametric polymorphism that so critically impeded their ability to write their application that they would trade away the simplicity of Go. Go was designed for a specific purpose, to write concurrent applications that are easy to reason about, both in terms of their concurrent aspects and performance as a whole.
It’s not just data structures. Functions shouldn’t have to be unnecessarily specialised.
This is really more of a philosophical point than a practical one. While such a feature is nifty, it’s not that useful. We can talk all day about how neat monads are (really neat), or how map is so more elegant than a for loop, but at the end of the day when you are writing an network server chewing through tens of thousands of requests per second, reasoning about the exact performance characteristics of a for loop is easier.
I want a Tree data structure
Why? Why not use a map? There are plenty of ways to use trees besides maps, ways that involve custom, non-generic logic to create and maintain the tree to reap some performance benefit or other desirable characteristic.
I hope I don’t have high standards by refusing to use a system which doesn’t allow using types as documentation or which asks for information it doesn’t need nor use.
You have different priorities. You aren’t wrong for your priorities, and your priorities don’t make all other priority sets wrong. You seem to be claiming that the lack of generics is so crippling that Go is trash not worth using, by anybody. That’s how I read your tone anyway. But that flies in the face of reality: plenty of people are accomplishing significant feats with Go, without generics. I originally asked what language features—or possibly characteristics of the problems Go is solving—accommodate the lack of generics. Why do the developers feel they aren’t useful enough to add? Defending Go has made me come up with concrete reasons, and I have answered my question for myself.
Very quickly you come to a point where you have to lie.
I don’t think so. Go is about making the simple decision, not the ultra nifty yet often unnecessarily complex one. Make the simple choice, and you don’t have to lie. That puts Go at the opposite end of the spectrum from languages like Haskell, a trait that a lot of people consider a feature.
-
Also, I should note that around 4 years ago I too thought Go was a sensible idea and I was using it for things but I noticed the problems and started using more capable tools.
-
This is really more of a philosophical point than a practical one.
No, code duplication is a very practical issue - it’s ridiculous to say otherwise.
.. reasoning about the exact performance characteristics of a for loop is easier.
Parametric polymorphism is not about for loops.
Why? Why not use a map?
Do you see the irony here? Making a false compromise in the name of performance but then sacrificing it by using a Map?
You seem to be claiming that the lack of generics is so crippling that Go is trash not worth using, by anybody.
Yes, I refuse to use a language which doesn’t allow code reuse and I’ll point out the silly false sacrifice made for “simplicity” reasons. I think more should have the same standards.
That’s how I read your tone anyway
I have no tone.
But that flies in the face of reality: plenty of people are accomplishing significant feats with Go, without generics.
People are accomplishing things despite the lack of generics, by not abstracting and not reusing code.
Why do the developers feel they aren’t useful enough to add? Defending Go has made me come up with concrete reasons, and I have answered my question for myself.
I have seen the answer, too. They put up with code duplication and don’t allow abstraction.
Go is about making the simple decision, not the ultra nifty yet often unnecessarily complex one.
Parametric polymorphism as a type system feature has been around for about 30 years now. It’s extremely simple to describe and implement.
Go’s “simplicity” (i.e. lack of parametric polymorphism) is a silly thing to trade for. Your application becomes more complicated because of no abstraction and no code reuse so that the language spec doesn’t spend a few paragraphs defining parametric types!
-
I just searched Twitter for #golang to see what other strange things were being said and I immediately saw this monster:
https://clipperhouse.github.io/gen/
The solution for lack of generics? A code generation tool!
https://github.com/clipperhouse/gen/blob/master/templates/projection/projection.go
This is simplicity?
-
-
C++ templates are just fancy code generation. Well, fancy is a stretch. Built in though.
Having a type system that handles generics is a better solution for generics, certainly. But code generation isn’t horrific in of itself. It’s one of many tools in the world of programming tools, and is fairly easy to work with. Protobufs use code generation to make parsers and interfaces, and that’s fine in my opinion.
-
I read: generics aren’t necessary, code generation rather than generics is fine.
Very strange ideas!
-
-
I can’t think of any nontrivial applications for which generics wouldn’t be useful. Besides code reuse, parametric polymorphism gives you better reasoning about what your code is doing via parametricity/free theorems.
-
- Linux kernel. Written in C, it obviously doesn’t use parametric polymorphism though it approximates it in some places. However, most of the algorithms and data structures are tuned for their particular use patterns, and thus the code is not generic.
- HTTP server. I can’t think of a reason to use generic anything. It’s mostly pushing bytes and data validation. The Go standard library includes a high performing concurrent HTTP server. Nginx and Apache are both written in C. Most file servers fit here, actually.
- Message buses. Any algorithms written for a message bus are fairly specific, and a non-trivial bus will have it’s own versions of all of them.
- Load balancers. TCP, UDP, HTTP, whatever you like, it’s a hash table sitting on a shitload of sockets. No polymorphism here beyond what Go provides.
- Firewalls. A firewall has to be low latency, basically transparent. Custom up the wazoo, an algorithm in a firewall can branch on anything in those header for any number of reasons.
- Databases. Skip lists seem like a great thing to make generic, until you start optimizing for more and more fields in the elements and it’s only works for DB records anyway. And more importantly, you want to know where every last byte is, all the time.
Now, I’m not saying that generics won’t be somewhat useful for a lot of these. Of course they would in some parts of code. But most of those use cases are covered with Go’s typing system. The amount of times you need to be able to specialize some code to literally any type ever is not that high. An interface will do just fine.
-
-
-
-
-
-
Yes, I refuse to use a language which doesn’t allow code reuse
They put up with code duplication and don’t allow abstraction.
Seriously?
Parametric polymorphism as a type system feature has been around for about 30 years now. It’s extremely simple to describe and implement.
Then why are C++ templates are such a mess? And why is it that Java generics are implemented with type erasure, don’t work with primitives, and aren’t safe with arrays?
You are right though, it’s even said on the Go site that some code duplication is the preferred solution to certain things. Many people find that a small amount of duplicate code is acceptable in certain circumstances, otherwise the industry standard would be Haskell. For an application that necessarily relies heavily on generic types, I wouldn’t pick Go.
Your application becomes more complicated because of no abstraction and no code reuse so that the language spec doesn’t spend a few paragraphs defining parametric types!
Exactly zero abstraction is ideal. Main is the only function anyone needs.
-
Then why are C++ templates are such a mess? And why is it that Java generics are implemented with type erasure, don’t work with primitives, and aren’t safe with arrays?
- C++ templates are not a great idea
- Type erasure is a brilliant idea
- Java’s generics definitely have problems and could have been done much better, that’s the problem with trying to retrofit generics and making compromises!
Exactly zero abstraction is ideal. Main is the only function anyone needs.
I truly hope and believe this is not a position shared by many!
-
A big part of the reason why generics are such a mess is because of the intersection of subtyping and parametric polymorphism. IMO, get rid of subtyping and use row polymorphism for records.
-
-
Your examples only show that retrofitting or piggy-backing on features to get parametric polymorphism has always resulted in sadness. Implementing generics as a goal is extremely simple - I’ve done it many times!
-
-
-
-
-
He listed earlier many “real programming languages” with parametric polymorphism. It’s not exactly a colony on Mars. This is something we’ve known how to do for literally decades. And saying that languages shouldn’t have parametric polymorphism because you personally think it’s difficult to implement is like saying cars shouldn’t have transmissions or 4-stroke engines for the same reason.
Not being able to write generic data structures in Go without casts is awful and basically inexcusable for a modern language that wants to be taken seriously.
-
He listed earlier many “real programming languages” with parametric polymorphism.
Which one has a perfect system? The Go developers won’t introduce one because they can’t see a clean way to do it that jives with the rest of the language.
And saying that languages shouldn’t have parametric polymorphism because you personally think it’s difficult to implement is like saying cars shouldn’t have transmissions or 4-stroke engines for the same reason.
Because it’s difficult to get right, for a lot of people, including the very capable people on the Go team. Side note, Tesla is doing well.
Not being able to write generic data structures in Go without casts is awful and basically inexcusable for a modern language that wants to be taken seriously.
I mean, it kinda sucks. I’ve never been that bothered. A lot of companies are writing critical infrastructure in Go, and the word critical implies they are taking it seriously. Writing correct, fast, and maintainable Go code is easy, and a lot of people like that.
-
-
-
-
-
-
-
-
-
-
-
-
-
There are no casts in Go. You can convert primitive types (such as string to []byte or int to float64), but when working with interface{}, you can’t convert, you can only do type assertions. Type assertions will fail if the asserted type doesn’t match, so you still have type safety at runtime. You still can’t hammer a square piece through a round hole.
-
so you still have type safety at runtime
There is no such thing as runtime type safety. Go’s “type assertions” are in every way a type cast.
-
T must implement the (interface) type of x; otherwise the type assertion is invalid since it is not possible for x to store a value of type T. If T is an interface type, x.(T) asserts that the dynamic type of x implements the interface T.
If the type assertion holds, the value of the expression is the value stored in x and its type is T. If the type assertion is false, a run-time panic occurs. In other words, even though the dynamic type of x is known only at run time, the type of x.(T) is known to be T in a correct program.
(Emphasis mine.)
So I’m afraid you are mistaken: type assertions are not at all like a type cast – at least not like a type cast in a weakly typed language like C, wherein they instruct the compiler to treat x as being of type T regardless of what its actual type at runtime is.
Now type assertions in Go do allow you to compile code that is not always correct, including code that is never correct. Nevertheless, they do not allow you to run code that is not correct, and thus are safe, much unlike type casts in a language like C.
-
Just because you can write this in Java:
if(x instanceof String) { println((String)x); }And it won’t crash, doesn’t mean you’re not casting.
-
I was responding to your claim that a) there is no such thing as runtime type safety and b) type assertions in Go are therefore not safe.
Now in what way is your Java code example unsafe? Will it ever run incorrect code? Not as far as I can tell.
It is clear that Java’s casting does allow you to compile incorrect code, like Go’s type assertions do. I’ve already said so. (Though arguably the code in your example is not even ever incorrect.)
So if you were trying to make a point about my reply, I can’t see what that is.
-
-
-
There is not such thing as runtime type safety.
Yes there is. Compare the result of running
python -c '"1" + 1'andphp -r '"1" + 1;'. The difference is a result of Python having more type safety than PHP, which is checked at runtime.-
The difference has nothing to do with types.
-
This is a form of safety, but it’s not static type safety. From Types and Programming Languages:
Refining this intuition a little, we could say that a safe language is one that protects its own abstractions. Every high-level language provides abstractions of machine services. Safety refers to the language’s ability to guarantee the integrity of these abstractions and of higher-level abstractions introduced by the programmer using the definitional facilities of the language. For example, a language may provide arrays, with access and update operations, as an abstraction of the underlying memory. A programmer using this language then expects that an array can be changed only by using the update operation on it explicitly—and not, for example, by writing past the end of some other data structure. [1]
So Go will let you know at runtime if you’re casting between two incompatible types, and this is a form of safety, but not static type safety. Similarly, Python won’t let you index past the end of a list, and this is a form of safety, but, once again, not type safety.
Pierce continues:
Language safety is not the same thing as static type safety. Language safety can be achieved by static checking, but also by run-time checks that trap nonsensical operations just at the moment when they are attempted and stop the program or raise an exception. For example, Scheme is a safe language, even though it has no static type system. [2]
In the end, this is mainly an argument about definitions, but it’s important to get these definitions right when discussing language design tradeoffs, especially when these definitions clue us in to real differences between languages.
For what it’s worth, I think Go’s lack of parametric polymorphism is absolutely crippling.
[1] Pierce, Benjamin C. (2002-02-01). Types and Programming Languages (Page 28). MIT Press. Kindle Edition.
[2] Ibid.
-
So Go will let you know at runtime if you’re casting between two incompatible types, and this is a form of safety, but not static type safety.
I don’t understand why you’re saying this. I’m not talking about static type safety. I’m talking about type safety at runtime. Puffnfresh has claimed that no such thing exists. I’ve provided a counter-example.
This is basically a conclusion drawn from the distinction made between strongly and weakly typed languages. It’s not like I’m pulling this out of thin air.
For what it’s worth, I think Go’s lack of parametric polymorphism is absolutely crippling.
For what it’s worth, I disagree.
-
Both PHP and Python only have a single type, so it’s kind nonsensical to claim that one has more type safety than the other at least using a TaPL definition of the word “type”. What they do have is different runtime semantics for handling values with different runtime tags, which colloquially these languages unfortunately refer to as “types”.
-
I cannot see any point you’re making other than to indulge in a definition war. If we were at ICFP and I started talking about the type safety of Haskell and Python as if they were the same thing, then I’d applaud your correction. But in a wider audience, it’s quite clear that comparing the type safety of languages like Python and PHP is a perfectly valid and natural thing to do.
-
It’s not a word game, my point is that I question whether this alternative definition of the term actually gives rise to a well-defined comparison or ordering at all. What could it possibly mean for a programming language to “go wrong less” than another programming language if they both admit an infinite number of invalid programs? Hypothetically If I have a language Blub can I always form a language Blub' that is less type safe than Blub and what would I have to alter to make it so? This kind of redefinition just leads to nonsense.
-
This kind of redefinition just leads to nonsense.
My example up-thread contrasting Python and PHP is absolutely not nonsense. The distinction between them is a result of a difference in each language’s type safety.
I mean, hell, if you try running the Python code, you’ll get an exception raised aptly named TypeError. What other evidence could possibly convince you?
-
My example up-thread contrasting Python and PHP is absolutely not nonsense.
It is a nonsensical notion if you take it to it’s logical conclusion, that there exists this alternative notion of “type safety” in terms of their runtime semantics that we can compare languages based on. Sure, you can contrast the addition function for a fixed set of arguments, but how do you generalize that to then make a universal claim like “Python has more type safety than PHP”.
If it’s a well-defined concept, then suppose I gave you [Python, Fortran, Visual Basic, Coq, PHP] what would be the decision procedure in the comparison “function” used to order these languages for your notion of type-safety?
-
It is a nonsensical notion if you take it to it’s logical conclusion
Why do I have to take it to its logical conclusion? The distinction exists today. Python is strongly typed and PHP is weakly typed. These descriptions are commonly used and describe each language’s type system.
Sure, you can contrast the addition function for a fixed set of arguments
The addition function? Really? That’s what you got out of my example?
Try this in a Python interpreter:
def x(): pass x(0)What do you get? A TypeError!
If it’s a well-defined concept
Who says it has to be well defined? I certainly didn’t. I’m merely drawing on the established conventions used to describe properties of programming languages.
I still truthfully don’t understand what your central point is. Are you merely trying to state that there exists some definition of type safety for which it is nonsensical to ascribe to dynamically typed languages like Python or PHP? Great. I never contested that. But that does mean you’re just playing word games, because it’s patently obvious that that definition isn’t being invoked when discussing type safety of precisely the languages that your definition of type safety doesn’t apply to.
-
-
OK. So you’re playing word games. Just as I thought.
Concepts such as strong and weak typing exist and they are used to draw meaningful comparisons between languages all the time. So you covering your ears and simply saying this doesn’t exist is a bit ludicrous.
-
They can’t and shouldn’t be used to draw conclusions about programming languages at all unless they have a precise meaning, which they don’t. The fact that they are used all the time to make specious arguments doesn’t make them any more accurate or precise, that’s just a consensus fallacy.
-
They can’t and shouldn’t be used to draw conclusions about programming languages
Except they are. I’ve given examples to support my claim. You’ve done nothing but appeal to your own definition.
I’ve committed no fallacy because I’ve drawn no conclusions from the fact that there is a consensus. I’ve merely pointed out that there exists a consensus. (Which you absurdly claimed doesn’t exist!)
-
I’ve merely pointed out that there exists a consensus.
No really, there isn’t a consensus on these terms. Even the Wikipedia article on the terms “weak and strong typing” prefixes everything it says by saying they have no precise meaning and that many of the proposed definitions are mutually contradictory, and should be avoided in favor of more precise terms. Probably this answer is the best explanation of why the terms are themselves completely meaningles, they’re just used for sophistic arguments to justify preconceived bias about language features.
Which is why I claim the defining this new term “runtime type safety” in terms of these other ill-defined terms is fallacious.
-
It boggles my mind that you think I’m trying to precisely define anything. I’m not. I’ve merely pointed to the facts: the terms weak typing and strong typing have meaning, and are used to compare and contrast language features in a way that effectively communicates key differences. These differences relate to the way types are handled at runtime.
I never once said that there weren’t any problems with these terms or that they weren’t vague.
Welcome to the subtleties of human language. You’re arguing about what should be. I’m pointing out what is.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
you still have type safety at runtime
There are two kinds of type safety: Static types and strong types.
What you are describing is strong types; safety at run-time. Static types go beyond that; they give safety at compile-time.
Now, in Java, generics are implemented with static type guarantee. But there is a catch; the type parameters are erased after compilation. Also, Java doesn’t support co-variant types, which means, you end up type-casting / type-asserting sometimes, though it is not very often.
However, if a language doesn’t support generics at all, then you have to use type-casts / type-assertions every time you need to reuse code!
-
However, if a language doesn’t support generics at all, then you have to use type-casts / type-assertions every time you need to reuse code!
And that language isn’t Go.
I swear, this whole thing is messed up. Gophers tend to overstate the power of structural subtyping and people who haven’t written a lick of Go seem to dismiss it entirely. Believe it or not, Go actually does have a mechanism for compile time safe polymorphism. And yes, that means static types!
-
The quoted sentence of mine was deliberately brief. There are many ways for a language to facilitate code reuse. Structural sub-typing allows code reuse in a different way than generics. You can’t create type-safe and re-usable collections with structural sub-typing for example.
-
I never implied otherwise. I made the comment I did because there are others in this thread that are repeatedly stating inaccuracies about Go. Namely, that it has no mechanisms for code reuse. Given that context, it’s unclear exactly what you were implying.
And that brings me back to my point. People seem to think that just because Go doesn’t have their favorite blend of polymorphism that Go has none of it at all. Or at the very least, completely dismiss structural subtyping simply because it’s different from what you like.
As far as code reuse goes, structural subtyping is only one piece of the puzzle. Go also has type embedding and properly implemented first class functions. (Which sounds like a weird benefit to quote, but not every language gets lexical scoping exactly right. Go does.)
-
-
-
-
-
-
-
A little off-topic, but really surprised that they don’t have an https server, and there are no checksums visible for the downloads.
-
The reasoning on https so far have been something like: the data on the webserver is open/public and the CA system is proven to be close to broken when it comes to ensuring identity, and the encryption part, too it turns out.
Buying the CDs might give you a reasonable amount of trust in the origin of the code, but you can’t really be sure when it comes to identity trust - it comes with a built-in bootstrap problem. If you trust the CD you will have a signify pubkey which will allow you to verify the integrity and identify of the online releases. Of course you might get this key in some other way. The signature has been released in several places and comparing those seem to be as good as it gets, unless you happen to know one really close to the release process.
The signed checksums can be found at http://ftp.openbsd.org/pub/OpenBSD/5.5/amd64/SHA256.sig
-
-
I would like to try OpenBSD for experimenting on my Desktop. Perhaps through a virtual-machine for now.
Is Java available on OpenBSD? Either Oracle JRE or OpenJDK. And is the latest version (8) available?
-
Latest OpenJDK in amd64 -current packages found at http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ is jdk-1.7.0.21p2v0.tgz which btw. seem to be the same version found in the 5.5 package set.
-
-
My first thought after reading that is that somebody clearly needs a hug.
Our code really isn’t that bad. It’s just that it has to interact with everybody else’s code, which is clearly a witches' brew of nonsense. Like the thingy that happens to throw exceptions that Visual Studio won’t catch, or the database that doesn’t do CTEs for some reason (cough, mysql, cough), or the ORM that you can tell to delete orphaned rows, but will only actually do it sometimes, or…
-
-
-
A whole novel based on this concept in reverse: http://www.baenebooks.com/p-1632-the-wizardry-compiled.aspx
Significantly better than the “back of book” would lead you to believe.
-
-
-
-
This might seem like a minor thing, but I think the visual design of the site might be contributing to the silence. All that white space and you the first one to spill ink on it!
Also, comment scores might make people more conscious of commenting and of the reward / punishment associated with it. Could it be hidden by default and only visible upon hover or something like that?
-
The feature is fantastic, but I wonder if the merging approach can be tweaked in some way.
The original Heartbleed story gives a good example: the merged comment by apy is only applicable to the old story. And while it might be a 4 point comment for that story, it ends up displayed over a threaded group of comments that are very interesting & useful - links to the fix, updates on individual vendors, etc.
And, again, while apy’s comment may be +4 in the pre-merged story, it becomes off-topic in the new one. That’s bad for the comments on the merged story, and it could end up bad for apy’s karma.
All in all having merging is far better than not, so I definitely don’t intend this criticism to be taken harshly. And unfortunately I don’t know what the fix might be. Just some thoughts for consideration.
-
-
-
Yeah, I think that’s probably fair. I’ve been trying to think about what kind of change could be applied (reorder comment display, no penalty for down votes after a story was merged, …) but I can’t think of any improvements that don’t add problems or make things worse.
You’re probably right - it’ll be good for 90% of comments, and that makes it well worth it.
Again, thanks, this is a really cool feature.
-
-
-
-
-
I too have been burned by this. If this is a feature, please provide an option to disable it.
-
-
I desperately don’t want Lobste.rs to become an aggregator of these sorts of links. I don’t even want a tag for this sort of content. It simply doesn’t belong here.
-
Yeah, these links aren’t even especially novel, useful, or worthwhile. Definitely not relevant to Lobsters. LMGTFY? Probably one of the most annoying passive-aggressive things on the web. MSOutlookIt.com? No one’s boss is going to be fooled.
-
-
-
I played with this today and found it a little awkward. ML-like languages can get rid of NULL because they have pattern matching. In fact, I couldn’t even get it to work. Something as simple as:
// class field public Optional<Character> gender; // toString return " gender=" + gender.orElse('U');The point being to return M/F (or whatever other character is set as gender) .. this still returns a null pointer exception, if gender is uninitialized. To initialize it one has to do:
public Optional<Character> gender = Optional.of('U');Which really defeats the purpose of using Optional (i.e. to avoid NPEs). I have no control over client code.
Am I wrong? Am I misunderstanding the expected behaviour?
-
-
yes (it’s expected behaviour and it defeats the purpose); it seems like the groovy / c# approach is more pragmatic (i think the elvis operator would do fine here?).
it seems like a language extension (.?) would be better than a clunky library class here.
-
I think to initialize the field you only need this:
public Optional<Character> gender = Optional.empty();which is a little better – you don’t need to think of or define a custom value for “unknown”.
And as others have said, yes, you still have to work around the fact that Java cannot guarantee that an object reference is not
null. An API’s use ofOptionalsignals that since the API uses it where possible, it probably won’t ever return a plainnull, so you don’t have to bother checking for NPEs from it. But you can still never be sure that you won’t getnull– the latest Java hasn’t changed that property of object references.
-
-
The one thing I desire from Rust is a portable binary format. I know it is aimed for system programs, but a portable binary format that can be AOT or JIT translated to native would “break the mold” and standout among the plethora of language implementations currently available.
-
Experimental JIT support was added two years ago, but later removed because of instability and limited dev resources.
-
-
hrjet
4 years ago
|
link
| on:
Text File formats – ASCII Delimited Text – Not CSV or TAB delimited text
I have created a (work-in-progress) Vim plugin, that uses Vim’s conceal feature to visually map the relevant ASCII characters to printable characters. It sort of works, but there are known issues which I have listed in the README.
-
For small scala projects I tend to use vim. But for larger projects, I can’t live without eclipse features such as on-the-fly error checking, organise imports, rename, and so on.
Moreover, if you use the vrwapper plugin, you get almost all the benefits of vim inside eclipse.
I want to believe, but there’s a reason that there are only 3 browser engines that are capable of running the modern web (each backed by enormous organisations).
(Unless they’re using big chunks of Gecko or WebKit, but the talk about Java makes that sounds very unlikely)
Nope, we aren’t reusing Gecko or Webkit or Blink. It’s pure Java.
We are also not aiming to run the whole modern web in the first cut.
Btw, this isn’t the first time something like this is being done. There’s HtmlUnit which is a headless browser in pure Java.