terrible programmers: my god, it's full of chars

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »

FamDav: Mar 29, 2008

of course since your build system is deterministic/pure you can just reuse the cached results of previous builds right

# ? Jul 16, 2014 06:56

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 12:59

Tiny Bug Child: Sep 11, 2004; Avoid Symmetry, Allow Complexity, Introduce Terror

uncurable mlady posted:

oh my god I loving hate JavaScript

you don't like good languages.

# ? Jul 16, 2014 06:59

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

whoever posted this guys blog

http://duartes.org/gustavo/blog/archives/

thanks. i'm slightly less bad

# ? Jul 16, 2014 07:55

Notorious b.s.d.: Jan 25, 2003; by Reene

Tiny Bug Child posted:

you don't like good languages.

you're right, I like PHP even less

# ? Jul 16, 2014 12:41

tef: May 30, 2004; -> some l-system crap ->

Shinku ABOOKEN posted:

thanks

so are there any advantages to unbound "this"? i see pain but i don't see gain. also the python way is 100% better.

ugh, here comes another :words:

dump

there are two big models when it comes to OO: PURE OO, APPROVED 100% BY ALAN KAY, and the not alan kay OO. they key difference is the former is objects recieve messages, and the other one is that objects are structures.

with smalltalk esque languages, like Obj-C and ruby, each object has a number of methods attached to it, and when you do obj.foo(args), you're really doing obj.send(:foo, args). objects are lightweight actors which can synchronously send messages to each other and get replies.

in ruby, if you want to capture a method to invoke later, you can something like m = obj.method(:foo), and then m.call(). ruby doesn't have functions. what it has is top-level methods on objects. print isn't a function, it's shorthand for self.print, and all objects inherit from the top level object, so print can be found.

(blocks are a little weird and sorta live on the call stack until wrapped up in a proc or lambda, or bound to a name. they aren't really functions. let's just ignore that ruby 'iterators' are closer to observers in reality)

these sorts of languages are "message based OO", the ones alan kay declared "true OO" (now, if you have asynchronous actors and messages you get someting close to erlang, which is why people say it's OO, but that's a total aside)

meanwhile in python, it's o = obj.foo; o(). when you call a method, you're looking up a value in an object. when you do obj.foo, you get back a function to call. methods are defined using functions that take an extra argument, self.when you look up a method o.foo, and foo is a function in a parent class, you partially apply o to foo as the first argument. (lua doesn't have this class magic, it uses two syntaxes foo.bar and foo:bar(..))

instances are just containers for functions. methods are just functions that take another variable. this is the heretical OO which is vaguely popular.

so instead of saying 'message based' and 'struct based' OO, we can also see it as 'OO from methods', and 'OO with functions'. judging by which feature came first. yes, in python, functions are objects too. o() the same as o.__call__() ?!. sure, yep, but calling a method involves binding a function and calling it. not sending a message. (this gets confusing when you have languages like java which use methods, but see objects as structures. whatever)

so: let's go back to the question about implicit this, explicit this, lexical this and runtime this. the choices between these make more sense when you understand the method/function divide.

ruby uses implicit this, but doesn't run afoul of javascript's issues, as blocks act as a weird pancea - they're lightweight closures that are linked to the containing object. you don't have to do this=that, which is why you have to lift them up to make them full objects, anyway. since methods are the main way of specifying code, having this be implicit is nice.

meanwhile python went the opposite way. functions are the main way, so making self an explicit argument was an easy way to transform functions into methods. it means you can do things like ClassA.foo = ClassB.foo to reassign methods, and 'self' is lexically scoped. if you want to use it in a closure, you don't have to bind or do that=this.

so, what is javascript?

instead of functions built from methods, or methods built from functions, javascript has methods which can be called as functions. foo(x) is if you called window.foo(x). javascript uses structure based OO too, so ClassA.foo = ClassB.foo too. javascript binds 'this' at method call time, rather than method lookup time in python. with python, it knows if it's an instance attribute or a class attribute, and only does method binding to the latter. with javascript, it's all prototypes, so there isn't that nice and easy option available.

so what have we learned?

x = obj.foo; x(blah); does completely different things. in python it's obj.foo(), in ruby it's self.x(blah), in javascript it's window.x(blah).

python's choice of explicit this roots from using fns+structures, ruby's implicit self from using methods+messages. javascript chose methods too, but going for structural OO.

# ? Jul 16, 2014 14:29

double sulk: Jul 2, 2010

I don't have much of an urge to write or learn any more Scala than I have to which is probably bad since it's the main language my company uses.

(Disclaimer: I'm a terrible programmer)

# ? Jul 16, 2014 14:29

tef: May 30, 2004; -> some l-system crap ->

(if you can't guess my favourite thing is to have message passing OO at a higher level between components, erlang style, built from structural like OO parts underneath built from functions. i really like explicit self. if you're hating on explicit self in python, you're probably writing too many methods.)

# ? Jul 16, 2014 14:32

Shaggar: Apr 26, 2006

tef posted:

ugh, here comes another dump

there are two big models when it comes to OO: PURE OO, APPROVED 100% BY ALAN KAY, and the not alan kay OO. they key difference is the former is objects recieve messages, and the other one is that objects are structures.

with smalltalk esque languages, like Obj-C and ruby, each object has a number of methods attached to it, and when you do obj.foo(args), you're really doing obj.send(:foo, args). objects are lightweight actors which can synchronously send messages to each other and get replies.

in ruby, if you want to capture a method to invoke later, you can something like m = obj.method(:foo), and then m.call(). ruby doesn't have functions. what it has is top-level methods on objects. print isn't a function, it's shorthand for self.print, and all objects inherit from the top level object, so print can be found.

(blocks are a little weird and sorta live on the call stack until wrapped up in a proc or lambda, or bound to a name. they aren't really functions. let's just ignore that ruby 'iterators' are closer to observers in reality)

these sorts of languages are "message based OO", the ones alan kay declared "true OO" (now, if you have asynchronous actors and messages you get someting close to erlang, which is why people say it's OO, but that's a total aside)

meanwhile in python, it's o = obj.foo; o(). when you call a method, you're looking up a value in an object. when you do obj.foo, you get back a function to call. methods are defined using functions that take an extra argument, self.when you look up a method o.foo, and foo is a function in a parent class, you partially apply o to foo as the first argument. (lua doesn't have this class magic, it uses two syntaxes foo.bar and foo:bar(..))

instances are just containers for functions. methods are just functions that take another variable. this is the heretical OO which is vaguely popular.

so instead of saying 'message based' and 'struct based' OO, we can also see it as 'OO from methods', and 'OO with functions'. judging by which feature came first. yes, in python, functions are objects too. o() the same as o.__call__() ?!. sure, yep, but calling a method involves binding a function and calling it. not sending a message. (this gets confusing when you have languages like java which use methods, but see objects as structures. whatever)

so: let's go back to the question about implicit this, explicit this, lexical this and runtime this. the choices between these make more sense when you understand the method/function divide.

ruby uses implicit this, but doesn't run afoul of javascript's issues, as blocks act as a weird pancea - they're lightweight closures that are linked to the containing object. you don't have to do this=that, which is why you have to lift them up to make them full objects, anyway. since methods are the main way of specifying code, having this be implicit is nice.

meanwhile python went the opposite way. functions are the main way, so making self an explicit argument was an easy way to transform functions into methods. it means you can do things like ClassA.foo = ClassB.foo to reassign methods, and 'self' is lexically scoped. if you want to use it in a closure, you don't have to bind or do that=this.

so, what is javascript?

instead of functions built from methods, or methods built from functions, javascript has methods which can be called as functions. foo(x) is if you called window.foo(x). javascript uses structure based OO too, so ClassA.foo = ClassB.foo too. javascript binds 'this' at method call time, rather than method lookup time in python. with python, it knows if it's an instance attribute or a class attribute, and only does method binding to the latter. with javascript, it's all prototypes, so there isn't that nice and easy option available.

so what have we learned?

x = obj.foo; x(blah); does completely different things. in python it's obj.foo(), in ruby it's self.x(blah), in javascript it's window.x(blah).

python's choice of explicit this roots from using fns+structures, ruby's implicit self from using methods+messages. javascript chose methods too, but going for structural OO.

gross

# ? Jul 16, 2014 14:34

Workaday Wizard: Oct 23, 2009; by Pragmatica

tef posted:

ugh, here comes another dump

there are two big models when it comes to OO: PURE OO, APPROVED 100% BY ALAN KAY, and the not alan kay OO. they key difference is the former is objects recieve messages, and the other one is that objects are structures.

with smalltalk esque languages, like Obj-C and ruby, each object has a number of methods attached to it, and when you do obj.foo(args), you're really doing obj.send(:foo, args). objects are lightweight actors which can synchronously send messages to each other and get replies.

in ruby, if you want to capture a method to invoke later, you can something like m = obj.method(:foo), and then m.call(). ruby doesn't have functions. what it has is top-level methods on objects. print isn't a function, it's shorthand for self.print, and all objects inherit from the top level object, so print can be found.

(blocks are a little weird and sorta live on the call stack until wrapped up in a proc or lambda, or bound to a name. they aren't really functions. let's just ignore that ruby 'iterators' are closer to observers in reality)

these sorts of languages are "message based OO", the ones alan kay declared "true OO" (now, if you have asynchronous actors and messages you get someting close to erlang, which is why people say it's OO, but that's a total aside)

meanwhile in python, it's o = obj.foo; o(). when you call a method, you're looking up a value in an object. when you do obj.foo, you get back a function to call. methods are defined using functions that take an extra argument, self.when you look up a method o.foo, and foo is a function in a parent class, you partially apply o to foo as the first argument. (lua doesn't have this class magic, it uses two syntaxes foo.bar and foo:bar(..))

instances are just containers for functions. methods are just functions that take another variable. this is the heretical OO which is vaguely popular.

so instead of saying 'message based' and 'struct based' OO, we can also see it as 'OO from methods', and 'OO with functions'. judging by which feature came first. yes, in python, functions are objects too. o() the same as o.__call__() ?!. sure, yep, but calling a method involves binding a function and calling it. not sending a message. (this gets confusing when you have languages like java which use methods, but see objects as structures. whatever)

so: let's go back to the question about implicit this, explicit this, lexical this and runtime this. the choices between these make more sense when you understand the method/function divide.

ruby uses implicit this, but doesn't run afoul of javascript's issues, as blocks act as a weird pancea - they're lightweight closures that are linked to the containing object. you don't have to do this=that, which is why you have to lift them up to make them full objects, anyway. since methods are the main way of specifying code, having this be implicit is nice.

meanwhile python went the opposite way. functions are the main way, so making self an explicit argument was an easy way to transform functions into methods. it means you can do things like ClassA.foo = ClassB.foo to reassign methods, and 'self' is lexically scoped. if you want to use it in a closure, you don't have to bind or do that=this.

so, what is javascript?

instead of functions built from methods, or methods built from functions, javascript has methods which can be called as functions. foo(x) is if you called window.foo(x). javascript uses structure based OO too, so ClassA.foo = ClassB.foo too. javascript binds 'this' at method call time, rather than method lookup time in python. with python, it knows if it's an instance attribute or a class attribute, and only does method binding to the latter. with javascript, it's all prototypes, so there isn't that nice and easy option available.

so what have we learned?

x = obj.foo; x(blah); does completely different things. in python it's obj.foo(), in ruby it's self.x(blah), in javascript it's window.x(blah).

python's choice of explicit this roots from using fns+structures, ruby's implicit self from using methods+messages. javascript chose methods too, but going for structural OO.

thanks

# ? Jul 16, 2014 14:38

Stringent: Dec 22, 2004; image text goes here

if there's anything I like about tef it's how polarizing he is. the responses to that post characterize the posters utterly.

the problem is, tef's views on programming are like the recent articles about US millenials' political views.

# ? Jul 16, 2014 14:57

prefect: Sep 11, 2001; No one, Woodhouse.
No one.; Dead Man’s Band

Stringent posted:

if there's anything I like about tef it's how polarizing he is. the responses to that post characterize the posters utterly.

the problem is, tef's views on programming are like the recent articles about US millenials' political views.

are you saying that millenials are terrible? i'm okay with that

# ? Jul 16, 2014 14:58

Stringent: Dec 22, 2004; image text goes here

prefect posted:

are you saying that millenials are terrible? i'm okay with that

way more depressing. i'm saying they're young.

# ? Jul 16, 2014 15:05

tef: May 30, 2004; -> some l-system crap ->

Stringent posted:

if there's anything I like about tef it's how polarizing he is. the responses to that post characterize the posters utterly.

the problem is, tef's views on programming are like the recent articles about US millenials' political views.

i have no idea what this metaphor means. i'm trying to explain the mechanics of a programming language design through it's interaction with other pieces, without going too far into detail.

# ? Jul 16, 2014 15:12

coffeetable: Feb 5, 2006; TELL ME AGAIN HOW GREAT BRITAIN WOULD BE IF IT WAS RULED BY THE MERCILESS JACKBOOT OF PRINCE CHARLES

YES I DO TALK TO PLANTS ACTUALLY

Stringent posted:

if there's anything I like about tef it's how polarizing he is. the responses to that post characterize the posters utterly.

i don't see anything polarizing in that at all :confused:

# ? Jul 16, 2014 15:24

Ussr: Sep 17, 2004; Wait, what?

for the first time in 9 years I'm working with a team of programmers that don't spend the majority of their time whining and yelling about someone else's bad code. They just hang out, write code and don't yell. which either means theyre all really good or all really bad.

# ? Jul 16, 2014 15:40

Squinty Applebottom: Jan 1, 2013

Ussr posted:

which either means theyre all really good or all really bad.

that doesnt really matter since they dont seem to be a bunch of whiny assholes which is like a unicorn

# ? Jul 16, 2014 15:42

Symbolic Butt: Mar 22, 2009; (_!_); Buglord

one thing that I like about lua is how it's very transparent about being "fake oop" with structs (tables).

or at least this was a cool thing about the "programming in lua" book.

# ? Jul 16, 2014 16:02

karms: Jan 22, 2006; by Nyc_Tattoo; Yam Slacker

tef posted:

i have no idea what this metaphor means. i'm trying to explain the mechanics of a programming language design through it's interaction with other pieces, without going too far into detail.

ya its p interesting

# ? Jul 16, 2014 16:09

fart simpson: Jul 2, 2005; DEATH TO AMERICA

Shaggar posted:

gross

shaggar was right

# ? Jul 16, 2014 16:28

Luigi Thirty: Apr 30, 2006; Emergency confection port.

had my interview

they asked me some c# technical questions and i could answer most of them but a few of them i couldn't :saddowns:

asked me if i knew how to use visual studio then showed me their codebase and their devices, which were pretty neat

they said the hiring guy wasn't there at the moment (i saw him heading out to lunch before I arrived) and they'd call me back later to set up an interview with him

op success i guess

# ? Jul 16, 2014 19:14

gonadic io: Feb 16, 2011; >>=

Luigi Thirty posted:

had my interview

they asked me some c# technical questions and i could answer most of them but a few of them i couldn't

asked me if i knew how to use visual studio then showed me their codebase and their devices, which were pretty neat

they said the hiring guy wasn't there at the moment (i saw him heading out to lunch before I arrived) and they'd call me back later to set up an interview with him

op success i guess

what kind of qs?

# ? Jul 16, 2014 19:27

Luigi Thirty: Apr 30, 2006; Emergency confection port.

AlsoD posted:

what kind of qs?

most of it was basic stuff really. what's a reference, what's a value, what's a static, what's managed code, etc, to know that i know what i'm talking about and that i actually wrote the example code i sent them. i got all of those but there were some c# memory questions i didn't know about. he did spend the beginning talking about how they wanted more to know that i have experience and know about object-oriented programming in general than specifics about c# since it's real hard to find local .net developers

# ? Jul 16, 2014 20:04

coffeetable: Feb 5, 2006; TELL ME AGAIN HOW GREAT BRITAIN WOULD BE IF IT WAS RULED BY THE MERCILESS JACKBOOT OF PRINCE CHARLES

YES I DO TALK TO PLANTS ACTUALLY

Luigi Thirty posted:

i got all of those but there were some c# memory questions i didn't know about

what like the different heaps and generations of garbage collection etc etc

# ? Jul 16, 2014 20:09

Luigi Thirty: Apr 30, 2006; Emergency confection port.

coffeetable posted:

what like the different heaps and generations of garbage collection etc etc

stuff like that, i haven't used c# for much more than toys and c++ (which i have used) doesn't have fancy things like "garbage collection" because it is "garbage"

# ? Jul 16, 2014 20:22

fritz: Jul 26, 2003

coffeetable posted:

what like the different heaps and generations of garbage collection etc etc

i dont know a dang thing about c#, does anybody want to drop some words thuswise?

# ? Jul 16, 2014 20:56

coffeetable: Feb 5, 2006; TELL ME AGAIN HOW GREAT BRITAIN WOULD BE IF IT WAS RULED BY THE MERCILESS JACKBOOT OF PRINCE CHARLES

YES I DO TALK TO PLANTS ACTUALLY

fritz posted:

i dont know a dang thing about c#, does anybody want to drop some words thuswise?

all i know is what i can remember from Under the Hood of .NET Memory Management, but:

.NET has several heaps: the ones you're likely to care about are the Small Object Heap (SOH) and the Large Object Heap (LOH).
the SOH is where most stuff ends up, and it's a compacted heap - new objects are allocated on the end of the heap, and when an object is GC'd, other objects are moved to fill the gap.
to optimize the garbage collection, an idea called "generations" is used. the idea is that if an object has been around a long time, it's not very likely to die in the near future.
how it works is that all objects on the SOH start in Generation 0. if a Gen 0 object survives a GC pass, it's promoted to Generation 1. Generation 1 objects are GC'd much less often than Gen 0 objects ("less often" by a factor of ten in fact iirc). and if a Generation 1 object survives a GC pass, it gets promoted to Generation 2. again, Gen 2 objects are GC'd far less frequently than Gen 1 objects.
the takeaway is that if an object is around for a long time, it'll likely end up in Gen 2 and take a looong rear end time to get GC'd.
so that's all happening on the SOH. the LOH is used for, well, large objects. large objects are either >85K in size or arrays of >1000 elements.
the LOH is garbage collected when Gen 2 of the SOH is garbage collected, but unlike the SOH, the LOH isn't compacted. moving all those giant objects about would be really inefficient. instead, it uses a free-space table to find space for new objects, and a copy-and-sweep approach for clearing out dead ones: live objects are copied into a new heap, then the entire old heap is freed. this obv takes ages + is the source of most noticeable GC hangs

# ? Jul 16, 2014 22:25

bobbilljim: May 29, 2013; this christmas feels like the very first christmas to me

tef posted:

(this gets confusing when you have languages like java which use methods, but see objects as structures. whatever)

lol. I know no-one was asking about java but "whatever" is a great way to explain it yup

# ? Jul 17, 2014 00:38

bobbilljim: May 29, 2013; this christmas feels like the very first christmas to me

Stringent posted:

if there's anything I like about tef it's how polarizing he is. the responses to that post characterize the posters utterly.

the problem is, tef's views on programming are like the recent articles about US millenials' political views.

you can tell who the "real programmers" are eh eh *wink*

# ? Jul 17, 2014 00:39

bobbilljim: May 29, 2013; this christmas feels like the very first christmas to me

t-t-triplepost but I would sure hope thinking about what's "under the hood" of c# memory management isn't necessary day to day.

# ? Jul 17, 2014 00:42

raruler: Oct 5, 2003; “Here lies a toppled god —
His fall was not a small one.
We did but build his pedestal,
A narrow and a tall one.”

bobbilljim posted:

t-t-triplepost but I would sure hope thinking about what's "under the hood" of c# memory management isn't necessary day to day.

yeah if you're dealing with mark and sweep day-to-day it better be because you're playing intramural curling

# ? Jul 17, 2014 00:44

Shaggar: Apr 26, 2006

yeah i've never worried about gc. memory and connection leaks, sure.

# ? Jul 17, 2014 01:15

syntaxrigger: Jul 7, 2011; Actually you owe me 6! But who's countin?

tef posted:

ugh, here comes another dump

there are two big models when it comes to OO: PURE OO, APPROVED 100% BY ALAN KAY, and the not alan kay OO. they key difference is the former is objects recieve messages, and the other one is that objects are structures.

with smalltalk esque languages, like Obj-C and ruby, each object has a number of methods attached to it, and when you do obj.foo(args), you're really doing obj.send(:foo, args). objects are lightweight actors which can synchronously send messages to each other and get replies.

in ruby, if you want to capture a method to invoke later, you can something like m = obj.method(:foo), and then m.call(). ruby doesn't have functions. what it has is top-level methods on objects. print isn't a function, it's shorthand for self.print, and all objects inherit from the top level object, so print can be found.

(blocks are a little weird and sorta live on the call stack until wrapped up in a proc or lambda, or bound to a name. they aren't really functions. let's just ignore that ruby 'iterators' are closer to observers in reality)

these sorts of languages are "message based OO", the ones alan kay declared "true OO" (now, if you have asynchronous actors and messages you get someting close to erlang, which is why people say it's OO, but that's a total aside)

meanwhile in python, it's o = obj.foo; o(). when you call a method, you're looking up a value in an object. when you do obj.foo, you get back a function to call. methods are defined using functions that take an extra argument, self.when you look up a method o.foo, and foo is a function in a parent class, you partially apply o to foo as the first argument. (lua doesn't have this class magic, it uses two syntaxes foo.bar and foo:bar(..))

instances are just containers for functions. methods are just functions that take another variable. this is the heretical OO which is vaguely popular.

so instead of saying 'message based' and 'struct based' OO, we can also see it as 'OO from methods', and 'OO with functions'. judging by which feature came first. yes, in python, functions are objects too. o() the same as o.__call__() ?!. sure, yep, but calling a method involves binding a function and calling it. not sending a message. (this gets confusing when you have languages like java which use methods, but see objects as structures. whatever)

so: let's go back to the question about implicit this, explicit this, lexical this and runtime this. the choices between these make more sense when you understand the method/function divide.

ruby uses implicit this, but doesn't run afoul of javascript's issues, as blocks act as a weird pancea - they're lightweight closures that are linked to the containing object. you don't have to do this=that, which is why you have to lift them up to make them full objects, anyway. since methods are the main way of specifying code, having this be implicit is nice.

meanwhile python went the opposite way. functions are the main way, so making self an explicit argument was an easy way to transform functions into methods. it means you can do things like ClassA.foo = ClassB.foo to reassign methods, and 'self' is lexically scoped. if you want to use it in a closure, you don't have to bind or do that=this.

so, what is javascript?

instead of functions built from methods, or methods built from functions, javascript has methods which can be called as functions. foo(x) is if you called window.foo(x). javascript uses structure based OO too, so ClassA.foo = ClassB.foo too. javascript binds 'this' at method call time, rather than method lookup time in python. with python, it knows if it's an instance attribute or a class attribute, and only does method binding to the latter. with javascript, it's all prototypes, so there isn't that nice and easy option available.

so what have we learned?

x = obj.foo; x(blah); does completely different things. in python it's obj.foo(), in ruby it's self.x(blah), in javascript it's window.x(blah).

python's choice of explicit this roots from using fns+structures, ruby's implicit self from using methods+messages. javascript chose methods too, but going for structural OO.

i now know why someone would research/study/write PLs for fun

thanks

# ? Jul 17, 2014 01:29

bobbilljim: May 29, 2013; this christmas feels like the very first christmas to me

Shaggar posted:

yeah i've never worried about gc. memory and connection leaks, sure.

this happens when you did something wrong, not when you didn't know every nuance of exactly how the gc works for exactly the version you're running on (they could change the implementation completely in the next version)

# ? Jul 17, 2014 01:33

bobbilljim: May 29, 2013; this christmas feels like the very first christmas to me

lol if your ORM doesn't handle closing connections properly :smugmrgw:

*unfolds deckchair, sits back and watches*

# ? Jul 17, 2014 01:39

Shaggar: Apr 26, 2006

# ? Jul 17, 2014 01:55

Papes: Apr 13, 2010; There's always something at the bottom of the bag.

So I'm a baddy programmer who is mostly familiar with Java. I have a phone screen for a junior .net position on friday. They are really similar but is there anything c# specific I should be reading up on? LINQ maybe?

# ? Jul 17, 2014 01:59

Luigi Thirty: Apr 30, 2006; Emergency confection port.

oh yeah apparently the place just finished porting their application from Delphi 2005 (I asked him if he knew that Delphi 2005 existed when he started working there, he did not) to .net

he also asked me if I had mongodb experience

# ? Jul 17, 2014 01:59

tef: May 30, 2004; -> some l-system crap ->

bobbilljim posted:

lol. I know no-one was asking about java but "whatever" is a great way to explain it yup

well it's been a long while since i looked at java, so my memory is hazy, and it was off topic

but java didn't have dynamic dispatch originally, so i didn't think it right to lump it with the rubys and the smalltalks. under the scenes the jvm is doing lookup with fully qualified method names, although invoke dynamic confuses things a bit. and method handles.

there really isn't a meta object protocol, or a notion of sending a message, or symbols in Java, and in java you can access the attributes of an instance. it's sorta sorta structural, except that java doesn't really have functions yet*, so you don't have the whole x = obj.f; x() thing.

whatever. it wasn't really relevant to explaining the accidental? design around javascript's methods that sorta act like functions, and dynamic this.

i mean, who knows. the whole everything is bound to window by default was probably some quick hack to make a feature work. or functions were added first before prototypes were. i mean who knows what brendan eich was doing. iirc prototypes were included as a gently caress java.

* or whatever project coin and poo poo is happening

tef fucked around with this message at 02:13 on Jul 17, 2014

# ? Jul 17, 2014 02:07

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 12:59

tef: May 30, 2004; -> some l-system crap ->

Papes posted:

So I'm a baddy programmer who is mostly familiar with Java. I have a phone screen for a junior .net position on friday. They are really similar but is there anything c# specific I should be reading up on? LINQ maybe?

at a guess.

- generics are different, no checked exceptions
- linq is hella neat.
- delegates are useful, as are extension methods. there is also using/idisposable.
- unsigned integers
- value types, nullable types

it's kinda lina a java with the bits that didn't work well or were used well removed, and some of the things that were missing that could be added because jvm compat wasn't an issue. but unlike another java descendent, scala, c# is for mortals

# ? Jul 17, 2014 02:18

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »