Like wiggity wack yo dude! dont be dissin my shizzle yo man!
Name:
Anonymous2014-06-30 10:19
The main problem of Go is statical typing, which have long been proven to be pseudo-scientific crackpottery, like strong AI.
Name:
Anonymous2014-06-30 11:33
>>4 The last I heard from SPJ was that Haskell is (he said this playfully) "useless" in the sense that it's academic and not suited for a lot industry of areas. It's still useful, the Real World Haskell movement is a good thing, especially because people are learning to adapt or create other useful programming languages to allow better correctness guarantees.
The true utility of Haskell is to show how useful certain concepts are. People have gone beyond that to make the guarantees stronger. In truth Haskell is a focal point for a certain body of knowledge. It's not bad, it's not like we'd be better off not knowing what Haskell and related languages have to say. You can write monads in nearly any language.
>>7 In that case I agree, I am learning myself haskell anyway
Name:
Anonymous2014-06-30 15:35
>>12 Yes. Haskell is good to know, and often good to use.
Writing code in something like Haskell isn't necessarily harder, in fact I think it's easier if you approach it tabula rasa. It's often seen as hard for the experienced programmers because it's not closely related to anything in their language tree. You can't reach for the same tools, but you do get other ones, about half of which are there to prove the other half actually works and are being used correctly.
Right now, Rust is trying hard not to become Haskell (OCaml really) for systems programming. It's a shame in a sense, but they're really terrified of looking threatening to C++ programmers. That's valid in a marketing sense, but as someone who fights viciously for the future he wants to live in I would rather be a little more daring in hopes that C++ programmers will acclimate via network effect if nothing else. I don't want it to become Haskell, but a zero-overhead and more practical OCaml with idioms intelligible to C++ programmers where applicable sounds about right.
Haskell is seen as hard, because it takes more lines of code to do useful things, like stateful code. Moreover, it is impossible to write efficient code in Haskell.
Name:
Anonymous2014-06-30 15:47
The Haskell hype is similar to the OO hype of some years ago. If you don't know it, you can't criticize it. If you DID know it, you wouldn't criticize it. If you DO criticize it, well clearly you just don't "get it". And of course there's a special "vocabulary" you have to learn to use appropriately -- call a 'method' a 'procedure' and you've grouped yourself with the incompetent wanna-be's.
Name:
Anonymous2014-06-30 15:48
>>15 You're wrong on both counts. 1) Haskell is seen as hard because of its heady libraries and loads of compiler extensions. The core of Haskell is really simple, though: lambda calculus and pattern matching.
2) It is totally possible to write efficient code in Haskell, as has been demonstrated lots of times. It's just hard to reason about performance with all that laziness and compiler aggression and nonstandard runtime workings going on. But if you do devote some time to optimization, you'll get efficient, Java or C efficient (which is good enough in the vast majority of cases).
Name:
Anonymous2014-06-30 15:58
>>14 Sure, you can write Fortran in anything but I mean in the context of writing idiomatic code. I don't think it would be all that hard to learn how to write that kind of code in Haskell if that's all you wanted to do.
>>15 I assume you're trolling because the efficiency thing is obvious bait, and Haskell sources aren't all that long unless you're comparing to something like J.
However the "useful things, like stateful code" quip is exactly what I'm talking about. Most of your code doesn't need to be stateful, even in languages that aren't seen as primarily functional. Fluent-style code in any language has a very low density of stateful operations. When you stop thinking about using interim side-effects as a means to get interim results and start focusing on expressing transformations between function input and eventual output, functional languages try to give you all the tools you need to do so painlessly. It is a different way of thinking, and that can be hard to grasp at first.
Name:
Anonymous2014-06-30 15:59
>>16 But it's true: the vast majority of criticism is that "ZOMG it haz no effects", "whatcha mean I can't mutate me some shit in a dope for loop, shizzle my nizzle?" and "it's academia and academia is useless, all useful things are created by braindeads like teh Guido".
>>13 Design decisions in Rust are driven primarily by the needs of Servo, which as you can imagine is a huge project with lots of people working on it. Hypothetical popularity isn't a big deal to them. They mostly want their program to work. So, many of the changes have been a direct result of trying certain features and observing whether they improved the development process of Servo, or made it worse. Very empirical.
Name:
Anonymous2014-06-30 16:09
MOZILLA QUALITY, SERVO CERTIFIED™
Name:
Anonymous2014-06-30 16:37
>>20 That's true in a lot of ways, but not entirely.
The developers have periodically expressed fear of becoming too much like Haskell or looking too much like OCaml. Familiarity to C++ programmers is often cited as motivation when modifying syntax or arguing against features. This has nothing to do with Servo, you can't measure something you don't have.
A good example is there was a pyramid of deeply nested matches in Servo (or maybe it was rustc) and separately IoResult handling was also really icky. Instead of solving the problems generally (do-notation and HKTs were popular requests) the half-measure of writing specific workarounds for each was taken. They were both very ugly, just less ugly than not using them.
There still hasn't been a language that makes C89 not worth using for systems programming and just about everything else.
Name:
Anonymous2014-06-30 19:42
>>25 I think C99 is a significant improvement, and C11 would be great if MS would shut up about C++ and implement it already. Who am I kidding? no VS user is going to try to compile my code.
If Rust had the libraries I'd bring it up. Right now it's pretty much only good for writing compilers and video games.
Name:
Anonymous2014-06-30 19:50
>>25 BLISS was pretty nice and it had way better macros than C.
Name:
Anonymous2014-06-30 20:04
>>26 C11 is a abomination but it has some useful stuff Same goes for C99 I use both
you can simplify this to "unemployed need not apply", because I've never seen an employed functional programmer.
Name:
Anonymous2014-07-01 10:08
>>31 So you only hire those who are already employed?
Name:
Anonymous2014-07-01 10:08
Why functional programmers always get fired?
Remember, there are potential negative consequences of retaining a poor performer after you've exhausted all the options available: - You'll annoy other members of your team, who may have to work harder to "carry" the poor performer. - You may promote a belief in others that you're prepared to accept mediocrity – or, worse, underperformance. - You may waste precious time and resources that could be better used elsewhere. - You may signal that some employees deserve preferential treatment. - You may undermine the whole idea of finding the best person for the job.
Name:
Anonymous2014-07-01 10:40
>>30 You mean like libraries for windowing, 2D and 3D graphics, font raster, asset management, linear algebra, physics, scripting, controller input and HMD support with speed in the ballpark of C? [ Check. ]
>>30 And the real world are retards who don't know what they are doing and cause people to die unlike the academics/professionals.
Name:
Anonymous2014-07-01 18:30
I thought functional programming went against the grain against ``enterprise'' but you guys also seem to make fun of that. Retarded noobs, functional is the future (quantum) and too hard for you low IQ mongrels. In the future there will be no such thing like libraries or 3rd party support, just the pure technical performance of the language (speed, efficiency, elegance, performance, expressiveness, safety, it must be at the top in all good qualities) will be the judge and ensurer of its popularity and use.
Name:
Anonymous2014-07-01 18:32
>>40 The problem is that modern functional programming languages are going the enterprise reddit way, see haskal
Name:
Anonymous2014-07-01 18:35
>>41 And if they didn't, you would say that the problem is that no one uses them. Fuck you. There's nothing bad in popularity per se, provided that popularity it based on merit and not on aggressive marketing.
>>42 I said nothing about popularity, you headless creature
Name:
Anonymous2014-07-01 19:04
>>41 All popular languages do that. It's a symptom of the fact that the enterprise segment not just the largest segment, it's the overwhelming majority. Even open source is full of enterprise nowadays.
Put another way, people are currently being paid to write code in all of the languages listed in this thread. For each language, someone was hired by some visible corporation within the past three months and someone will be hired within the next three. They're all enterprise.
Alright guys, for school we have to make a portfoloi project showing off our coding abilities. I decided to kill two birds with one stone and create Mirage++. This one will be coded a lot better then the old version. Now that i have a year of college under my belt i actually know how to do things possibly. All networking is handled by Raknet a industry standard. The graphics are directx. All the editors are external so it wont slow the client down. This post is mainly just to manage my updates when i make them. Not a lot to look at at the moment.
I have only put 4 days of work into this so far as i just started. But in my final quarter i will be pouring my time into this. If i do not return home for the current 2 week break then i will be working on it a ton aswell.
Audio and Graphics: I currently have a proffessional audio student creating custom free to use audio for the engine and the games created with it. I hope to get a graphics artist to do the same.
Map Editor: I am currently using the OGMO map editor. It is open source and provides the tools i need. Once Eclipse++ is done i may make my own map editor. But this manages everything i need allowing me to spend more time on the actual engine. Tilesheets appear in a seperate window so you can dual monitor map.
Any sized maps. The map will start to scroll if it wont fit on the screen. Giant maps! want 4000 tile maps? No problems. Only loads the relevant tiles. Have a 10000 tileset but only use 100 on the map? Only 100 are loaded. Maps are loaded Via XML so any map editor will work if a switch is needed. Maps will then be converted to binary to reduce file size.
Main is as clean as it can be with a state manager that will manage the entire game. I am trying to keep the code as simple as i can so that everyone will understand it.
//==================================================================================================== // Includes //====================================================================================================
bool SGE_Update(float deltaTime) { // Update Cursor Position gCursor.Update(deltaTime);
// check if we need to change state if (gNextState != GameState::Invalid) { if(gCurrentState != NULL) { gCurrentState->Unload(); delete gCurrentState; } //switch states switch(gNextState) { case GameState::FrontEnd: gCurrentState = new FrontEnd(gRaknet); break; case GameState::Gameplay: gCurrentState = new GamePlay(gRaknet); break; }
// enter the new state if(gCurrentState != NULL) { gCurrentState->Load(); } } // update current state gNextState = static_cast<GameState::Type>(gCurrentState->Update(deltaTime));
if (gNextState == GameState::Quit) { gRaknet.Disconnect(); gQuit = true; }
>>47 Now we'll spend most of our time waiting for the fucking compiler to complete. Everybody raves about how awesome dependent types will be but everybody seems to forget that type checking and type inference are a pain in the ass with that crap.
Name:
Anonymous2014-07-01 23:24
typechecking is NP-hard
Name:
Anonymous2014-07-02 5:25
>>52 Proving an invariant is undecidable via the halting problem. Typechecking a program with dependent types reduces to proving invariants.
Name:
Anonymous2014-07-02 6:10
>>53 So how's your bachelors in computer science from your no-name unicollege going, faggot?
>>54 I will not confirm or deny my having or not having a bachelors in computer science, but if I did have one, it wouldn't be going anywhere.
Name:
Anonymous2014-07-02 10:49
Typechecking a program with dependent types reduces to proving invariants.
In case anyone is falling for this, typechecking dependent types is just automated proof checking. >>53 is trying to tell you that it's the same as automated proving, which it isn't. Supplying the proofs is the programmer's responsibility.
>>57 Select one: 1) Sure, he is smart but is he Abelson smart? 2) Sure, he is poor but is he Abelson poor?
Name:
Anonymous2014-07-02 16:55
>>38 Because English the best language in the world. In fact, I think everyone should program in it. Since that's not a reality, the most practical language is C.
All great programmers always program in C and that will always be the case. Real programmers shouldn't have to worry about any advancement from mathematics. That kind of stuff is impractical because computers and programming obviously have neither relations nor origin to such a discipline. And I do not care to learn or believe otherwise! Please continue to argue with me.
Name:
Anonymous2014-07-02 18:26
>>59 Wrong, Hangugmal is the best language. English is a terrible! mashup of a bunch of euroshit.
>>60 I've never heard of this Hangugmal. And I won't look it up, which makes it already inferior to Haskell. This leaves English as the most superior language and C as the best programming language.
Writing code in something like Haskell isn't necessarily harder, in fact I think it's easier if you approach it tabula rasa
Bullshit. Lazy evaluation makes reasoning about performance really hard for no practical gains. I'd argue that learning Haskell has your first language is practically impossible.
Bullshit. Homophones make reasoning about word selection really hard for no practical gains. I'd argue that learning English as your first language is practically impossible.
English is a homophone=fag communication. It was created to allow international communication of fags.
Name:
Anonymous2014-07-03 12:03
>>66 The practical gain is that computation is deferred to when it's strictly needed and that the logic to achieve this behavior is trivial to write and that you can get powerful results from a tiny amount of logic. Yes, this level of abstraction makes it opaque to try and reason its logic for the sake of performance. I take opinion that the higher level abstract logic makes it easier for the compiler to apply higher levels of optimization to the abstract code. I think this is the difference between using a declarative language like Haskell where the compiler is supposed to be powerful and all knowing and using an imperative language like C where programmers are supposed to instruct the compiler because the compiler doesn't understand the programmer's high level intent.
I'm bored with this thread. These were my troll posts. >>37 >>59 >>64 /poe's law
Anyone who posts similarly silly arguments and actually believe them are self-deluded and not worth your time. I applaud those who ignored these posts.
Name:
Anonymous2014-07-03 13:16
>>73 If you don't know when to schedule a computation, you've done your analysis wrong.
I think this is the difference between using a declarative language like Haskell where the compiler is supposed to be powerful and all knowing and using an imperative language like C where programmers are supposed to instruct the compiler because the compiler doesn't understand the programmer's high level intent.
>>79 Lisp is special language on a class of its own. I'd class it as a multi-paradigm language foremost. With Lisp macros, you can write a Lisp language that is imperative style or functional style.
Name:
Anonymous2014-07-03 23:25
>>82 It's like you think Lisp is the only language with useful macros.
>>86 It doesn't have static typing unless you want to consider things like Qi
Name:
Anonymous2014-07-04 11:25
Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark.
To be fair he was probably saying in his own way that he really liked what the STL does for him in C++. For the purpose of argument, though, let's take his claim at face value.
What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types.
But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types.
That's the detail that sticks with me.
Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive.
My late friend Alain Fournier once told me that he considered the lowest form of academic work to be taxonomy. And you know what? Type hierarchies are just taxonomy. You need to decide what piece goes in what box, every type's parent, whether A inherits from B or B from A. Is a sortable array an array that sorts or a sorter represented by an array? If you believe that types address all design issues you must make that decision.
Name:
Anonymous2014-07-04 14:24
>>84 It isn't though. Hell even Javscript has decent macros now.
Name:
Anonymous2014-07-04 14:33
>>89 Your standards for decent macros must be really low.
Name:
Anonymous2014-07-04 14:34
Hipster god ``tj holowaychuk'' leaving Node.js for Go:
>>90 Sweet.js does a good job in spite of the fact that JS isn't homoiconic.
Lisp's macros certainly aren't the best, given that many are equivalent and some are arguably better. Io doesn't even need to hook into the run time (no fucking with the reader) except when you define new operator symbols.
Everything he says under "Embedded Programming" is shit and he is an uneducated pig
Name:
Anonymous2014-07-06 1:29
>>94 Non-deterministic GC overhead is the reason languages like Go can't be used for real time systems. There are languages that try to ensure that the GC's share of a program's total execution time is well bounded (e.g., Real Time Java) but as far as I know no one has tried to do this with Go. Go's creator and major promoter (Google) does not use Go in applications where this sort of thing is a concern.
I'll agree that some of >>1's comments on unsafe operations are off base. If you don't have a lot of code that does direct hardware interaction you can just write that stuff in C and hide it behind Go's C FFI. And if you do have a lot of code that bangs directly on the hardware, your program is probably poorly designed. Even things like C language kernel mode drivers typically don't touch the hardware in more than a handful of carefully selected locations in the source. Anything else is hell to debug and test.
>>95 You are right and I would not use go for something like this (I actually would not use it at all) but this does not change the fact that >>1's link says bs about this
Name:
Anonymous2014-07-06 11:41
>>94 His wording about heap allocation is pretty weird. What he's trying to say is you have to be able to avoid calling malloc() ever. I agree with that.
I'm not sure if he's written code for one of these microcontrollers. I haven't, but writing code for an ARM chip with a few kb of TCM worked out pretty similarly to what he describes. I had malloc() but it was used to request allocations in EWRAM by carrier pigeon so I could later deliver data there by horse-drawn carriage, or more likely, send carrier pigeons to the other components asking them to send carriages with data directly to EWRAM, or vice-versa.
>>95 What's off base about that? I mean sure you can write FFI, but nobody is going to accept that for a language deemed suitable for embedded programming. Except the gophers.
I don't know what's better, the sweet sweet tears of gopher's failure to write an OS kernel, or Rob Pike's admission that he should never have described Go as a systems language.
Name:
Anonymous2014-07-07 3:56
>>97 Did the gophers really try to right a kernel? Why would you try to write a scheduler and memory management system in a language that requires both as a runtime component already?
I always assume that Rob just forgot to include the words "Google backend" in front of "systems language". He seems to be vulnerable (as so many of us are!) to forgetting that his current set of applications isn't the whole world.
Name:
Anonymous2014-07-07 7:31
>>98 Well they had a modified go compiler or runtime or something and eventually gave up on account of "fuck this!" I think they had something bootable, but I doubt there was a scheduler or even a program loader. No idea really.
He seems to be vulnerable (as so many of us are!) to forgetting that his current set of applications isn't the whole world.
Like that time he said you don't need to care about endianness because only compiler writers like himself need to know about it. Show me a modern codec that doesn't care about endianness. "That's not a website" is not an answer, Rob.
works no matter what the representation of uint32_t happens to be. You only need to care about what the representation of the bytestream is, which is fine. It may indeed generate faster code on some systems if you just do
val = *(uint32_t *) lebuf;
but this isn't universally true or portable in any way.
Show me a modern codec that doesn't care about endianness.
For multimedia, I'd hope that any endianess issues would be handled in the format demux code (which is probably IO bound anyway) rather than in the compressor / decompressor where speed is actually important.
>>103 The example he gave is applicable in many places, though. My point is that using the portable method in >>101 in mux code (probably) doesn't have a huge performance impact.
Name:
Anonymous2014-07-08 19:11
>>104 What's really going on is you're taking great care about endianness, presuming that it is in conflict, taking the time to realign your data and perform two extra copies to avoid screwing it up.
Suppose: the raw stream is in memory, the CPU clock rate is in the low/mid tens of MHz with memory clocked to match, memory is not byte-addressable, the cache is write-through and there are two three other processors talking to RAM. Demux will still be pretty quick in isolation, by using something like 4-8x as much memory bandwidth.
All that probably isn't the case, but you're probably not writing console games for portables. You're probaby not even writing code, but if you do, please don't let the likes of that narcisist tell you what you can and can not do.
What he's actually trying to say is that in the normal order of things, semantic clarity and portability should be more important to you than writing every single line in the highest-performance way imaginable. If you decode byte-ordered values in the way he suggests, your code will work on both big-endian and little-endian architectures. In certain cases you can speed up your code by explicitly writing it as a noop, but that's an optimization, meaning you shouldn't do it prematurely. Ideally your compiler (or at least your standard library) would be smart enough to do it for you.
>>106 Who said anything about premature optimization? The technique measurably breaks down in the scenario described, and it doesn't survive after profiling. Someone has to understand endianness explicitly and write byte-order-aware code, because guess what: not all compilers are at the theoretical limit of smartness. The current common solution is to call an inlined function that is a no-op when its unneeded.
I didn't bring this up to debate the technique. It is fine most of the time. The point was Pike didn't make it in the spirit of kindness. He granted exception to exactly one class of person, one he finds himself in. He pulls this shit all the time. When people didn't flock to Go in big enough droves, he complained that the hangers-on were stupid/ignorant/whatever.
Suppose: the raw stream is in memory, the CPU clock rate is in the low/mid tens of MHz with memory clocked to match, memory is not byte-addressable, the cache is write-through and there are two three other processors talking to RAM. Demux will still be pretty quick in isolation, by using something like 4-8x as much memory bandwidth.
The lack of byte addressability in particular means a C compiler will have to go to great lengths to avoid generating horrible code. I have done work on crappy architectures like the ones you describe and, frankly, having to check the compiler's code generation all the time becomes such a chore you may as well just rewrite your code in assembly once you know its performance is going to be a problem. This is especially true if you plan on ever changing your compiler (it's not fun, seeing your code miss half its deadlines because somebody had to change a compiler flag).
The point was Pike didn't make it in the spirit of kindness. He granted exception to exactly one class of person, one he finds himself in. He pulls this shit all the time. When people didn't flock to Go in big enough droves, he complained that the hangers-on were stupid/ignorant/whatever.
If you want to say Rob Pike is a bit of a self-important whiner we are in complete agreement. He pulled the same crap when Plan 9 didn't catch on in industry (see: Utah2k, where he spends half of his presentation insinuating that people who still do real work developing for Unix systems are fools).
>>106 Precisely. And in cases where the compiler isn't smart enough, tweaking the source isn't always the best answer.
I was told only compiler writers have this problem so I gave an example of something I've personally encountered. You yourself claim to have experience with what I regard as the most oddball aspect: memory which is not byte-addressable. This kind of weird collections of constraints is all over the place in the embedded world.
where the compiler isn't smart enough, tweaking the source isn't always the best answer.
What is the best answer? To switch compilers, incurring the kind of nightmare problems you describe above? That's not always even an option. Besides, if you're working with the same chip all the time, endian-awareness is not difficult. It's not like portability is a common concern in constrained systems. Usually the code is going to run on one device.
Name:
Anonymous2014-07-09 20:43
<vanila> hey <simcity2000> vanila: hi <vanila> what about a module system with SML style functors? wouldn't that make go cooler <simcity2000> vanila: no <taruti> actually doing generics with SML like module system would be kind of nifty :) <vanila> simcity2000, why not? <simcity2000> vanila: cool isn't the metric for defining how good a language is, but that aside I think you'd need a pretty different notion of types to make that sort of thing work in Go <vanila> simcity2000, oh when I thought it through, I thought this would work without any changes to go - the reason I bring it up is because it solves the generics/polymorphism problem <Tv`> vanila: nice troll <vanila> Tv`, you've seen me here for weeks, you know I'm not trolling. What's are the bad vibes for? <jmoiron> there've been a lot of trolls today <Tv`> vanila: "generics" ... "thought it through" .. "without any changes to go" <vanila> Tv`, simcity2000 said it would require changes to the type system - I was trying to say that it wouldn't. If this is a touchy/painful subject I'll talk about it with other people I know that are interested in go than you all <Tv`> good luck on your chosen path <simcity2000> vanila: it's an interesting idea if you're going from the generics angle <taruti> vanila: what issues do you think there are with type system semantics with SML style modules and Go? <taruti> *simcity2000 <vanila> taruti, You cannot create a homogenous linked list along the lines of http://golang.org/pkg/container/list/ - you can create a hetrogenous list this way. If you had SML style modules you could get the best of both worlds <taruti> vanila: yes, I know... <Tv`> e-dard: "solution", right <vanila> taruti, That was in answer to the question you asked me <taruti> vanila: no. * bfrog (~tburdick@unaffiliated/submersive) has joined <vanila> why are you all being so rude to me and acting so hurt? <taruti> vanila: I was trying to ask simcity2000 what issues they think there would be fitting them together from a type system soundness perspective. <simcity2000> taruti: I was actually thinking about Haskell-style functors, where you have a functor typeclass that relies on generic types <taruti> simcity2000: Haskell type classes are very different from SML modules. <simcity2000> apparently I don't know SML-style functors. * nemothekid has quit (Quit: My MacBook has gone to sleep. ZZZzzz…) * scottferg (~scottferg@c-98-226-208-95.hsd1.il.comcast.net) has joined <simcity2000> taruti: that's what I just picked up <vanila> yeah I don't think you guys have understood what I'm suggesting, that would explain Tv` who is normally intelligent calling me a troll Tv`!*@* added to ignore list. <simcity2000> vanila: feel free to elaborate, I don't have much to do atm <vanila> simcity2000: Well it's just a small change to make modules parametrized, then you could do generic containers in a type-safe way * skitoo has quit (Quit: Leaving...) <simcity2000> taruti: are SML functors just a $something that takes in structures with a given signature and produces new structures? <e-dard> Tv` I think you misunderstood the issue. I'm doing that already. The issue is packages test binaries get run in parallel by default (if you have a multi-core cpu)
Name:
Anonymous2014-07-09 20:45
<vanila> hey <simcity2000> vanila: hi <vanila> what about a module system with SML style functors? wouldn't that make go cooler <simcity2000> vanila: no <taruti> actually doing generics with SML like module system would be kind of nifty :) <vanila> simcity2000, why not? <simcity2000> vanila: cool isn't the metric for defining how good a language is, but that aside I think you'd need a pretty different notion of types to make that sort of thing work in Go <vanila> simcity2000, oh when I thought it through, I thought this would work without any changes to go - the reason I bring it up is because it solves the generics/polymorphism problem <Tv`> vanila: nice troll <vanila> Tv`, you've seen me here for weeks, you know I'm not trolling. What's are the bad vibes for? <jmoiron> there've been a lot of trolls today <Tv`> vanila: "generics" ... "thought it through" .. "without any changes to go" <vanila> Tv`, simcity2000 said it would require changes to the type system - I was trying to say that it wouldn't. If this is a touchy/painful subject I'll talk about it with other people I know that are interested in go than you all <Tv`> good luck on your chosen path <simcity2000> vanila: it's an interesting idea if you're going from the generics angle <taruti> vanila: what issues do you think there are with type system semantics with SML style modules and Go? <taruti> *simcity2000 <vanila> taruti, You cannot create a homogenous linked list along the lines of http://golang.org/pkg/container/list/ - you can create a hetrogenous list this way. If you had SML style modules you could get the best of both worlds <taruti> vanila: yes, I know... <Tv`> e-dard: "solution", right <vanila> taruti, That was in answer to the question you asked me <taruti> vanila: no. * bfrog (~tburdick@unaffiliated/submersive) has joined <vanila> why are you all being so rude to me and acting so hurt? <taruti> vanila: I was trying to ask simcity2000 what issues they think there would be fitting them together from a type system soundness perspective. <simcity2000> taruti: I was actually thinking about Haskell-style functors, where you have a functor typeclass that relies on generic types <taruti> simcity2000: Haskell type classes are very different from SML modules. <simcity2000> apparently I don't know SML-style functors. * nemothekid has quit (Quit: My MacBook has gone to sleep. ZZZzzz…) * scottferg (~scottferg@c-98-226-208-95.hsd1.il.comcast.net) has joined <simcity2000> taruti: that's what I just picked up <vanila> yeah I don't think you guys have understood what I'm suggesting, that would explain Tv` who is normally intelligent calling me a troll Tv`!*@* added to ignore list. <simcity2000> vanila: feel free to elaborate, I don't have much to do atm <vanila> simcity2000: Well it's just a small change to make modules parametrized, then you could do generic containers in a type-safe way * skitoo has quit (Quit: Leaving...) <simcity2000> taruti: are SML functors just a $something that takes in structures with a given signature and produces new structures? <e-dard> Tv` I think you misunderstood the issue. I'm doing that already. The issue is packages test binaries get run in parallel by default (if you have a multi-core cpu)
<vanila> yeah I don't think you guys have understood what I'm suggesting, that would explain Tv` who is normally intelligent calling me a troll Tv`!*@* added to ignore list.
What is the best answer? To switch compilers, incurring the kind of nightmare problems you describe above? That's not always even an option. Besides, if you're working with the same chip all the time, endian-awareness is not difficult.
Sometimes it's better to just give up and write the assembly yourself. That at least protects you from awful breakage that can happen even when changing compilation options on the exact same compiler, or upgrading to a newer version of same. I'm not saying that assembly is always the best choice but if changing compilers is a more likely event than changing ISAs it has its benefits.
If the unthinkable happens and you do happen to switch to a different chip later, assembly also has the nice property of making it totally obvious what code was written with ISA specific assumptions in mind. If you have co-workers that apply guards like #if __LITTLE_ENDIAN__ to 100% of the code they write, I want to know what magical environment you work in because everyone I've ever known will fuck this up if you're aren't testing for bi-endianness.
Sometimes it's better to just give up and write the assembly yourself.
That's fine, but I'd consider that tweaking the source and then some. I'm not arguing against the practice. I mean the cases where you need to care about this stuff and the cases where you end up writing assembly have quite a lot of overlap.
If you have co-workers that apply guards like #if __LITTLE_ENDIAN__ to 100% of the code they write
No, that's a pipe-dream. The upside is you can put this into library code and fail code review if someone tries to write their own. Maybe it's already there, try man 3 endian. Note the functions are all either htofoo or footoh, so they are portable modulo availability.
>>94 Re: "Everything he says under 'Embedded Programming' is shit and he is an uneducated pig"
Hmm, actually it looks like Oberon might be a better choice for embedded programming, if only someone would download the Oberon sources and change all the CAPS LOCK keywords to something more sensible (pretty easy fix). Go Language is after all just a plagarized copy of Oberon (half serious - it is inspired by Oberon). But oberon allows you to use the Stack, which is great for embedded programming... Go language leaves you heaps of shits, but Oberon allows you to stack a deck of cards. The big problem with Oberon is CAPS LOCK IS UGLY and the reserved words could be more terse (PROCEDURE could be shortened to "PROC" or "pro". Oberon programmers are hypocrites when they use VAR, instead of VARIABLE. So if they use VAR, why not use PROC instead of PROCEDURE? Because they are hypocrites. So someone could download oberon and make it usable! Wirth will never be convinced since he's stuck in academic obscurity and does not seem to interact with any developers whatsoever on any mailing lists or usenet - out of site, out of mind.
