From the textbook that thought there was a java.io.OutputStreamReader
-
CALDARI FOR LIFE, BABY!
Well, used to be, no time for EVE these days. Also, I heard they nerfed my beloved Drakes to hell
Yes, Drakes, shut up! I rocked that thing like nobody's business!
@The friend that plays EVE said:
It got nerfed years ago. Because it was stupidly over-powered
It's still a nice boat.
-
shortly followed by:
@The friend that plays EVE said:
No, no...
FEROX FTW! PEW!
-
Because everything is string really in JS.
new Array(16).join("hi" - 1) + " batman!"Try it in your chrome console ....
-
all i want to know about that game is:
is "Ramming Speed" followed by "All hands, brace for impact!" a valid set of instructions with real gameplay effects?
because my favorite space based combat games always have at least one kamikaze based fight.
i love killing my enemies star bases and dreadnoughts with mosquitos.
It is a valid set of instructions with real gameplay effects; I've done it before on quite a few occasions. Shields work as advertised in the Eve 'verse though, so ramming doesn't do damage; instead, you get an elastic collision, which is handy on those occasions you wish to alter your foe's trajectory, say to stop them from running away or to push them out of the range of their support. You can even ram friendlies in much the same way, although the usecases for that are somewhat more...niche.
-
huh. well that's not as much fun.
-
huh. well that's not as much fun.
I'd link a video where a swarm of noob ships kills a cruiser but it would require too much context, and I think this thread had enough EVE for one night :P
-
I am guessing that at least you have seen this based on your example, but for anyone who hasn't:
-
It is a "fun" classic.
[16].join("hi" - 1) + " batman!"Is 16 batman!, you can fuck about all day but you just gotta be aware that this silly crap can happen.
-
Because everything is string really in JS.
No, not everything is really a string in JS. And a number isn't even always a number (try 3.length vs. var a = 3; a.length), while a boolean is always a boolean (false.length is undefined, really). You can cast too many things to a string though, likea = {}; a[["u",["g","l"],"y"]] = "!"; aI don't know what the JS designers were smoking, but it should be banned forthwith!
-
For the most part things behave like them. Tbh you only run into these things when doing od things.
-
This post is deleted!
-
Hmm?
abstract finalcontradicts each other, or was that changed in Java 8?You can add
synchronizedand/orstrictfpand/ornativeif you want to, though.
-
Oh yeah, forgot about those.
Also,
synchronizedmethods are evil, I had to work with an API that would deadlock due to crossing the streams ofsynchronizedmethods.Of course, the synchronized-ness is considered part of the public API for some reason, so it can't be changed. Even though NOBODY USES IT because it's broken.
-
well, [no][1].
but almost everything will autocast to a string.It's a PITA until you learn how it works.
EDIT: that doesn't means that autocast isn't a WTF
[1]: http://msdn.microsoft.com/en-us/library/ie/7wkd9z69(v=vs.94).aspx
-
Of course, the synchronized-ness is considered part of the public API for some reason, so it can't be changed. Even though NOBODY USES IT because it's broken.
Worse. It's implementation isn't broken. It works. It's just that it incredibly easily leads to code that is just plain wrong-headed: it's a broken design.
The
synchronizedblock is OK though.
-
I disagree here; in fact, for 90% of people I think you'd have a hard time coming up with a language that I think is worse than C to start with, save for languages like Brainfuck that are made as a joke and maybe something like APL or COBOL. FORTRAN is maybe the only contender that I can semi-realistically see being used somewhere.
FWIW, I've been part of a few different introductory courses on the teaching end (mostly as a TA, though). And by introductory, I mean that 50% or more of the students weren't familiar with the concepts of variables or functions. The very idea that you can type a list of stuff that the computer will eventually do seemed magical to some of them. (Which is OK, everybody needs to start somewhere.) So, regardless of what you show, it'll seem "magical", and you'll lose half of the students.
The problem with Java (IMHO) is that the noise-to-signal ratio of the first program that you'll show is pretty much only noise and no signal. I.e.:
"public"? We'll tell you all about that in a few weeks. "class"es you'll learn about in a week or two. The "public static void" is also important, so, eh, don't forget to type it, ok? Then there's that String-thing that's a parameter to a function .. but, oh, you guys don't know what a function is yet - well cover that today - so don't worry about that either, ok?
C is a bit better at that point. There's less noise to begin with, and some of the noisy stuff you can skip to begin with. (C++, on the other hand, is a lot worse, at least if you stick to the std::cout stuff.)
The course where most of the students "get it", is from my observations, the one where they start with assembler on a microcontroller (4 weeks), followed by C (another 4 weeks). Mostly, because for these guys, the very fundamental things like variables and functions are something they (or most of them) understand. (Sure, learning ASM for some uncommon platform is of dubious value by itself. But, again, they become comfortable with the fundamental stuff.)
Filed under: Why the fuck is the preview window off-screen?
-
My worst Java textbook was Objects First. Fuck Objects First.
CultureFactory heteroProgrammingPatriarchy = new CultureFactory(); ICulture myCulture = heteroProgrammingPatriarchy.makeRapeCulture(); myCulture.fuckObjects(); myCulture.fuckPrimitives();Hmm...I don't see the problem.
-
As to your point: Python, in many ways, has a more pervasive OO notion than even Java. Dig into the way the built-in file, function, and class types work, sometime if you want to see the pervasiveness first-hand...
This topic comes up every so often. Some people have confused OOP with class based OOP and dismiss prototype OOP as faux OOP.
-
The problem with Java (IMHO) is that the noise-to-signal ratio of the first program that you'll show is pretty much only noise and no signal.
They'd probably be better off with some scripting language for first exposure. Or maybe a functional language like Haskell. ;-)
The key is that they really ought to have something where they type stuff in and it happens immediately. Dealing with compilation and so on isn't something they should be hit with until they're up to the point where they can cope with “the computer does what I tell it to” and “I can put the instructions into a text file for later use”.
Java (or C#; the differences in this respect are minimal) makes more sense once you move from single-file-of-instructions to something larger. That's the case that it's tuned for.
-
```
CultureFactory heteroProgrammingPatriarchy = new CultureFactory();
ICulture myCulture = heteroProgrammingPatriarchy.makeRapeCulture();```java CultureFactory heteroProgrammingPatriarchy = (CultureFactory) new InitialContext().lookup("java:defaultCultureFactory"); Culture myCulture = heteroProgrammingPatriarchy.getCultureBean("cultureType=rape");Sorry. Too much dealing with this sort of thing…
-
Yeah, even though my day job involves a lot of java, I don't deal much with that sort of stuff directly, and rape culture didn't motivate me enough to make a more enterprisey joke.
-
They'd probably be better off with some scripting language for first exposure. Or maybe a functional language like Haskell. ;-)
Well, one of the many different groups of students that take the microcontroller course with ASM+C have actually had a Haskell course first.
From that group of students, there's always a few that manage to make a real mess by using recursion for everything (like, why use a loop when you can recurse?). Which, I suppose, is fair enough, except that (a) the C-compiler for that microcontroller is a bit dated and slightly ... "special", and (b) there's only a few kb of stack space (which is crammed into the same few kb of memory that also contain the main program and everything else). Turns out, it's really hard to debug anything when your stack has overwritten half of your program. (This isn't really the students' fault, though. It'd probably be a valuable lesson of sorts, if this weren't students from the first year.)
The key is that they really ought to have something where they type stuff in and it happens immediately.
Incidentally, Java is being thought for the Physics-students. For those especially, something like Python would make a lot more sense (matlab is already being thought^W briefly shown). Most of those students will need to solve numerical problems (at least during their studies), and not build cute GUI apps with clickety widgets. (Which is basically what the Java course focuses on toward the end.)
Dealing with compilation and so on isn't something they should be hit with until they're up to the point where they can cope with “the computer does what I tell it to” and “I can put the instructions into a text file for later use”.
That's a pretty good point.
-
Well, one of the many different groups of students that take the microcontroller course with ASM+C have actually had a Haskell course first.
When I was an undergraduate, CS students started with Standard ML. (Haskell wasn't a production-ready thing back then.) I learned it later; I switched courses when I discovered that the one thing I couldn't stand to be was a lab chemist…
-
It wasn't my first language (BASIC and C came before), but I have always had a soft spot in my heart for Pascal. The power of C without lots of mysterious crap. Yes, it's more verbose (you have to type "begin" and "end" instead of "{" and "}", but I find it much more readable.
Object Pascal does (in my opinion) OOP right, and the FreePascal compiler is cross-platform and easy to use. Lazarus even gives it an IDE and GUI builder!
Honestly, I think that Object Pascal balances simplicity with the ability to do very advanced work better than any other language I know.
-
My first programming courses were C++ with no OOP in sight. OOP came in a later course. The exercises were almost like C with strings and vectors. Plus dynamic memory allocation on the second course that wasn't mandatory for the construction tech, mechanics or architecture students.
I'd still teach a beginner's class in C++. That way I wouldn't need to switch languages when it came time to discuss the deeper workings of software.
I would probably change the learning environment though. Working with jed, make and g++ through an SSH shell on the school's servers scares off a lot of bright minds. And needs a web connection at all times while working.
I think I'd introduce Qt Creator for that. Works on most desktop OS's, and supports C, C++ and javascript out of the box.
-
I had some variant of BASIC as my first language. Well. Unless you count batch files. I was thinking along the lines of "I could ask the user their name, then save it in an environment variable, and use that as a friendlier command prompt, and maybe change some settings based on the name of the user...." when I heard about this cool summer camp where they learn you real programming skills. I flew through their BASIC tutorial (I want to say they used something like... TrueBasic?) and graduated into C++ fairly quickly, and the rest was history.
-
This topic comes up every so often. Some people have confused OOP with class based OOP and dismiss prototype OOP as faux OOP
I read "faux OOP" close to "fuxup". Blame the French.
I learned with C++ at the tender age of 6; I didn't learn about functional languages like LISP until I was in high school, and I don't think I understood them until eight or so years later, somewhat ironically when I started to really heavily use Javascript.
-
When I was an undergraduate, CS students started with Standard ML. (Haskell wasn't a production-ready thing back then.) I learned it later; I switched courses when I discovered that the one think I couldn't stand to be was a lab chemist…
Never got to learn Haskell properly myself (nor ML or Lisp), since I started out studying spherical cows in vacuum and didn't make the switch until a bit later. Though, Haskell did most definitely exist at that point...
Apparently for my programme, they had "just" (academic "just") made the switch to Java, from Ada. Not sure if that was an improvement or not.
-
Never got to learn Haskell properly myself (nor ML or Lisp), since I started out studying spherical cows in vacuum and didn't make the switch until a bit later.
I learned ML entirely from a book (ML for the Working Programmer) without a computer. I worked through the entire book over a summer, doing all the exercises on paper, evaluating all the semantics by hand. Very good practice, really. Only the exercises using floating point values were impossible to do that way; FP does not yield easily to manual calculation.
The next academic year, it turned out that I knew ML better than all the other students. Though the book was a set text, I was the only person who had actually bothered to attempt all the exercises.
-
Worse. It's implementation isn't broken. It works.
Actually, no, the code didn't work.
Which is why literally nobody used that part of the API.
-
-
Only if it's a Fixed Point!
-
I'd advise against arguing with the words of Ridcully.
-
Incidentally, Java is being thought for the Physics-students. For those especially, something like Python would make a lot more sense (matlab is already being thought^W briefly shown).
I assume that you meant "taught", and not "thought"
"thought" and "matlab" in the same sentence makes no sense
-
I assume that you meant "taught", and not "thought"
"thought" and "matlab" in the same sentence makes no sense
Oops :-)
-
Actually, no, the code didn't work.
If only! If
synchronizeddidn't work, we wouldn't be having this debate because Java would either not work at all or thesynchronizedkeyword would never be used. However, it does exactly what it was described to do; thesynchronizedkeyword on a method functions correctly like an internalsynchronizedblock immediately inside the method that synchronizes on the context (thisor the current class, depending on whether it is an instance method or a class method). It's just that lots of programmers had no idea how to use the feature, and so made some truly horrible blunders with it. Some of those blunders were in the Java standard library —StringBuffer,VectorandHashtableremain testaments to stupidity to this day — but they were definitely not the greatest sins engendered in the name of concurrency in Java. I've seen worse. (This code for example, but I don't expect you to spot the problem. It took us long enough to find and patch the issue even though we knew it had to be in there because it was a really subtle concurrency fuckup. That's the codebase I work on at the moment; go easy on it, please.)It's very simple:
somemanymost programmers appear to have no fucking clue when it comes to concurrency. Concurrency is not easy to get right; you typically can't use the usual set of abstractions (functions, types, etc.) to reason about it because it's got a significant number of non-local aspects to it. Non-local properties are hard to reason soundly about…
-
.... The code, not the
synchronizedkeyword.The code in the API / implementation did not work.
Concurrency is not easy to get right; you typically can't use the usual set of abstractions (functions, types, etc.) to reason about it because it's got a significant number of non-local aspects to it.
This is almost right, you just need a different set of tools. Have you tried golang? Channels + goroutines make for concurrency that's very easy to get right.
-
Channels + goroutines make for concurrency that's very easy to get right.
That's all message/queue based, isn't it, based off of something like a typed CCS or π-calculus? Yeah, that's one of the easier models to work with, though if they're able to share mutable state across threads, they've still got the potential for deep crazy.
Deadlock is not the only global concurrency problem. In fact, it's one of the easier ones…
-
Okay, the issue was that if a message came in on the chat thread while a plugin was processing a chat message on the main thread, then.... It looked like this.
This deadlock would reliably happen to anyone actually using the Conversation objects, so the solution was that nobody used them. Then when I tried to fix it (let's call that "removing the black borders" here), people claimed that the
synchronizedpart of the methods were part of the public API. I'm claiming that is a WTF.
-
I'm claiming that is a WTF.
I would agree, but it's not a WTF because
synchronizeddoesn't work. It's a WTF because it does work but it is enormously abused and is hard to use correctly. The problem is one of design and community practice…
-
func SendToTwoPlaces(in <-chan Foo, out1, out2 chan<- Foo) { var done bool var queue1, queue2 []Foo for !done || len(queue1) != 0 || len(queue2) != 0 { var x1, x2 Foo var o1, o2 chan<- Foo if len(queue1) != 0 { x1 = queue1[0] o1 = out1 } if len(queue2) != 0 { x2 = queue2[0] o2 = out2 } select { case x, ok := <-in: if !ok { done, in = true, nil break } queue1 = append(queue1, x) queue2 = append(queue2, x) case o1 <- x1: queue1 = queue1[1:] case o2 <- x2: queue2 = queue2[1:] } } }selectis so nice
-
The problem is one of design and community practice…
Definitely.
Luckily, they had a few good designers, and there was a shift towards better API design towards the end.
-
Here's a version that takes any number of channels of any type:
func Multiplex(in interface{}, out ...interface{}) { done, queue := false, make([][]reflect.Value, len(out)) vin, vout := reflect.ValueOf(in), make([]reflect.Value, len(out)) for i, v := range out { vout[i] = reflect.ValueOf(v) } for { var cases []reflect.SelectCase var index []int if !done { cases = append(cases, reflect.SelectCase{ Chan: vin, Dir: reflect.SelectRecv, }) index = append(index, -1) } for i, q := range queue { if len(q) != 0 { cases = append(cases, reflect.SelectCase{ Chan: vout[i], Dir: reflect.SelectSend, Send: q[0], }) index = append(index, i) } } if len(cases) == 0 { for _, v := range vout { v.Close() } return } chosen, recv, ok := reflect.Select(cases) i := index[chosen] if i == -1 && !ok { done = true } else if i == -1 { for i = range queue { queue[i] = append(queue[i], recv) } } else { queue[i] = queue[i][1:] } } }
-
... and apparently Discourse thinks that code is C#.
-
... and apparently Discourse thinks that code is C#.
Anti-tool blame? Discourse uses a plugin/library/whatever for syntax highlighting, but to be fair, you should fork it, and any @ben_lubar code should be instantly recognized as Go.
When I do a mention, should the username list pop up in the preview panel?
-
@chubertdev - Days Since Last Discourse Bug: 0
-
Go is not in the default Highlight.JS package. https://highlightjs.org/download/
I put in a request for a update, but all languages is way too much. Huh, did I forget to submit the smaller one? Oops...
-
It doesn't even support the whitespace language.
-
people claimed that the synchronized part of the methods were part of the public API. I'm claiming that is a WTF.
Well, if you want supporting evidence for your side of the issue, here's a WONTFIX from 1999 where Sun's position is that
I'm not saying that the linked bug isn't a wtf all of its own, just that the official position of the makers of Java is thatsynchronizedis an implementation detail.
synchronizedis not part of a method's signature.
-
When I do a mention, should the username list pop up in the preview panel?
I have only rarely seen this elusive username list. I just manually type my @mentions, apparently too fast for the helper to appear.
Wat
Bug ID: JDK-4294756 Javac should warn if synchronized method is overridden with a non synchronized
