The Whiteboard - 2016-03-04 (page 3 of 3)

« first day (2009 days earlier) ← previous day next day → last day (2995 days later) »

8:00 PM

indeed it is, but the point I'm trying to make is that, at least here, what people look at is the keywords on your CV and the first phone interview.

and years of experience, I guess.

user55340

Doing "programmer, programmer, register at fast food" and applying for a job would be at issue.

user55340

or "enterprise Java, enterprise Java, local websites in php"

I've started putting "member of Oxford Hackspace" on my CV and nobody seems to care. My last employer even thought it was an organised computer hacking club. It wasn't until 3 months into the job that that got clarified.

i

Miguel van de Laar

@MichaelT The latter being worse

8:01 PM

I'm not sure it would be an issue here. though I probably wouldn't event list it.

oops, wrong window had focus

excellent comment nonetheless.

@PhilLello JUST DIED IN YOUR ARMS TONIIIIIGHT

Miguel van de Laar

@MetaFight Having a hole in one's CV is often a problem too

user55340

Hole is not ideal. Low skill filler - is it worse?

8:03 PM

@MiguelvandeLaar In my experience, it really isn't. But that's just my local work ecosystem. I wouldn't admit to taking a break in the US.

user55340

And as a developer, hole with "worked on open source project" or similar isn't necessarily bad at all.

@MichaelT I also thought I'd have to justify the hole, but nobody asked why I took a break. most people didn't even notice.

Miguel van de Laar

I guess that's a great way to fill the hole.
Though here employers might accept filler jobs when you have a family to take care of and jobs are sparse

user55340

I was laid off, took a several month break of home improvements and hobbies that I hadn't had time to work on in the previous 5 years.

them: "why is there a 9 month gap in your work experience?"
you "I was freelancing."
them: "what did you work on?"
you "I can't say... NDA."

user55340

8:06 PM

> “Jerry thought about what a letter of recommendation from a council of wizards would look like in his resume file.
"Totally secret," he said firmly.”

Miguel van de Laar

@MetaFight Getting close to lying at a job interview... Risky in the long run

user55340

( goodreads.com/work/quotes/966723-the-wizardry )

It sounds like keeping a career going is pretty god damned stressful in the US.

I worry that Canada will be the same when I chose to return in a few years.

user55340

@MetaFight There are secure jobs and there are riskier jobs.

user55340

The secure jobs are partially secure because of the associated stress and crap from them.

user55340

8:08 PM

I could still be working at Employer^^... but I would have many more gray hairs than I do now.

I always wonder if the job market sounds terrible just because the people experiencing these problems are the ones who talk the most about it, or if it really does suck this bad for everyone (and I'm merely overdue)

Miguel van de Laar

@MichaelT Lucky... You'd still have hair

user55340

@MiguelvandeLaar its retreating.

@Ixrec interesting point. So your experience has been positive so far?

@MichaelT I'm sure it's just to regroup.

user55340

8:09 PM

@Ampt that would be further down my back... no.

@MetaFight I'm still at my first job, and have basically no complaints whatsoever about it.

@Ixrec cool. congrats :)

I had a career gap of several years when circumstances turned me into a full-time carer, then ended up taking whatever work I could get. It's taken a good few years for people not to look that far back on my CV, but does mean recent work has been much less challenging than my preferred career path. Fingers crossed I've almost got back to where I was before everything fell apart 12 years ago.

user55340

Part of it is the hiring process... which sucks. Then there's also the thing of tech companies often find themselves on the boom bust of the market.

I didn't have any complaints about my first job either... until I left, got a bit more experience and perspective, and noticed they were completely taking advantage of me.

but, that's life.

8:10 PM

I mean, we have terrible legacy Fortran code, but no one's expecting us to make major changes in that part overnight

user55340

If you are in a non-technology company that recognizes the importance of technology... could be quite good.

in fact our top priority for the first half of this year is permanently deprecating the main apps which depend on it

@PhilLello which country are you working in?

@MichaelT I'm in a financial company that is trying to make its brand image more like that of a technology company (for recruitment purposes), does that count?

user55340

@Ixrec forbes.com/sites/oreillymedia/2014/05/13/…

8:12 PM

UK. I actually moved to Canada for a bit just after returning to work, and since out-of-country experience is largely ignored, no one was that interested that I'd had a gap!

user55340

The thing is that technology isn't the revenue driver.

But came back to the UK 2 years later

@MichaelT I was paraphrasing our own management on that one but yes very true article

user55340

Technology as revenue driver companies are a bit more... volatile.

our revenue driver is financial data services, so yeah we have the low volatility win

user55340

8:14 PM

Wallmart is a logistics company with retail... and that technology is a cost savings or revenue multiplier - but it isn't the source of the $.

@PhilLello You mention your career 12 years ago. I've only been working for about 7 years. Maybe you're at a level of experience where gaps matter more?

I can see it being a problem to go from being a knowledge worker to unskilled labor and then interviewing for knowledge work jobs again.

I love walking by co-workers desks and noticing my avatar on their screen.

user55340

Heh... in /r/scala on reddit:

user55340

> https://jobs.walmart.com/us/jobs/668439-5022/SUNNYVALE-CA-Principal-Software-Engineer?lang=en-US
We are looking for a talented Data Engineer to join the product recommendations and personalization team. Our team generates many of the item recommendations on Walmart.com, including the most prominent ones on product pages and cart pages and drive a significant percentage of Walmart.com product views and revenue.
Most of our code is in Scala. We use scalding for the most part and may also look at Apache Spark soon. Any kind of functional programming experience is a plus, but we are primarily…

user41796

@MichaelT Walmart works on some really, really interesting problems due to their scale

8:20 PM

Logs in and downvotes

@MetaFight Possibly, but I think the biggest problem with gaps on a CV is that people infer the reason for it rather than asking - explanations about personal circumstances shouldn't live on a CV. The biggest hurdle is due to a largely broken recruitment system, where generic agencies that don't understand the tech and/or client block CVs going forward. Directly approaching employers seems to be the best way of getting re-started after a break, but large companies also have HR filtering.

user41796

regrettably, the jobs are often in bentonville and they tend to pay below market rates

user55340

@GlenH7 Yep. I recall some careers.SO posts they had a few years ago... really interesting place with what appears to be a place with techies.

user55340

That one was in Sunnyvale.

Sunnyvale? Isn't that where Buffy & co live?

8:22 PM

I'm feeling like I'm getting to understand C as I read it. That's good, right?

user55340

user image

3

@JimmyHoffa One of those buzzwords that you can't find by searching for things like "having as copy paste"

@AaronHall Most languages are based on C structurally, so that's to be expected

user41796

@MichaelT And downtime in the datacenter is very, very, very expensive for them

It's like, ok, that's the type, that's preprocessor macro stuff, etc...

user55340

8:24 PM

@AaronHall C is not that hard of a language.

user55340

(my 5 languages to know: the-whiteboard.github.io/language/2016/02/19/… )

user41796

it's only difficult when you venture into the esoteric parts

C tends to have useful conventions - # introduces pre-processor directives, macros/constants are UPPERCASE most of the time.

user55340

Its #1 on the list.

user41796

@PhilLello The only downside is that a lot of those conventions are tribal knowledge and aren't written down

8:25 PM

Yeah, but it doesn't include the essential Python.

.... and C function pointers always look incredibly ugly

@GlenH7: my brother works for walmart and a lot of them are n00bs apparently

user41796

54 secs ago, by GlenH7

it's only difficult when you venture into the esoteric parts

not in bentonville though

user41796

@whatsisname It wouldn't surprise me. Given their lower salaries, they aren't going to be as competitive in who they can select

user55340

8:27 PM

@whatsisname they're hiring in some not traditionally tech markets. And probably building large teams that need to be growing.

theres this guy he has to work with that every time he closes a window he waves at the computer screen and says "goodbye" out loud

Esoteric C? I don't think such an animal exists... ok, maybe varargs are a bit obscure, but other than that....

user55340

Its very much like Employer^^ where everyone was a noob or not wanting to leave the area (or both).

user55340

@PhilLello consider a list implementation... where the get and put methods for the list are pointers to functions. So that you can switch the underlying implementation without breaking the other code that uses it.

user41796

@whatsisname epic

user55340

8:28 PM

@AaronHall You know you could write your own 5 languages set...

@GlenH7True, but the K&R C book is pretty tiny and covers it. I've read longer novels.

user55340

Bjarne Stroustrup: The 5 Programming Languages You Need to Know

user55340

Larry Wall: 5 Programming Languages Everyone Should Know

@MichaelT Well, that's not all that esoteric - it's C++ virtual functions where your object is the list element and the function pointers are the vtable. Although that's describing a horse by starting with a horse-drawn cart.

But probably anyone new to C these days has seen OO

user55340

(Larry's: (small light) Javascript, (big heavy) Java, (for geniuses by geniuses) Haskell, (because it is) C, (scripting and Larry) Perl)

user55340

8:41 PM

(Bjarne's: C++ (of course), Java, Python, Javascript, C (and of course C#)... and beyond that, something quite weird - pick a functional language)

@MichaelT I'd take out Java and name Haskell, and then I'd be at 4.

Oh, had a very in-depth tech interview yesterday, which was nice, but caught me off guard. One question was around memory allocation and fragmentation, and I'm still not convinced my answer was wrong, although it wasn't what the interviewer took as correct. Assuming the presence of an MMU, I'd say that fragmentation doesn't limit the biggest chunk of memory you can allocate, because the LA/PA translation makes fragmented memory look like a contiguous chunk.

Was I wrong, or does it vary by OS, compiler, libc, etc?

Admittedly, starting address and length of previously allocated memory will have some impact, but since physical memory is almost always < addressable memory, it shouldn't be a real-world issue

user41796

@PhilLello I believe that's correct. Fundamentally, that's the promise of the memory manager - it handles that manipulation for you.

user55340

@AaronHall Consider writing your set of 5 and why you think thats a good set to know.

user41796

But it also depends upon how the fragmentation is counted against the application

user41796

8:47 PM

If the fragmentation causes the already allocated memory amount to appear larger than what has actually been allocated, then there would be less available. But I'm not certain that's actually what would occur

So OS/compiler dependant then. Fair enough. Although another question proposed that network IO is expensive, and wanted an explanation of why. Turns out the expected answer was because of the memory copying from kernel-space to user-space. I'm assuming some of these were trick questions to gain an insight into my thought processes.

user41796

@PhilLello Network IO is expensive because it's comparatively slow.

user41796

But it depends upon the type of network as well

That was my first answer - network bandwidth. But then we moved into talking about within the stack once hardware has delivered to the kernel.

user41796

I'm not so certain about that copying cost from kernel to user space. Regular user data doesn't enter the kernel memory, AFAIK

8:57 PM

I'm hazy about the correct terminology there - I'd have thought the hardware / device driver part of data reception would be using kernel memory, and it's not in user space until the read/recv call. Anyway, too low level for my brain on a Friday night.

Really caught me off guard though - primary language for the dev aspects is currently PHP, so very unexpected!

Personal Home Page? People still use that?

user41796

@PhilLello some device drivers are required to be in kernel space, yes. But as a protective measure, many of them have been pushed out to user space. Or at least that was my understanding

@AaronHall I'm trying to get away from it, but yes, lots do.

Miguel van de Laar

@AaronHall Sadly, yes

what's fair to ask in an interview? If they say they know Python, but don't know all the uses of the keywords, should you pigeonhole them as a junior dev?

9:06 PM

@AaronHall Depends what other languages they know - I'd say a strong senior dev can probably code in most languages, but won't necessarily know all the keywords for every language.

depends on a lot of things

Most languages are either suped-up or dumbed-down C. Exceptions include assembly, BASIC, and possibly functional languages.

Miguel van de Laar

@AaronHall Have them explain concepts and approaches to given problems, matching those that are likely encountered in the project(s) they are hired for.

@AaronHall I agree with Miguel there. Algorithms and flow control are the important bit; visibility modifiers for OO languages.

@AaronHall senior/junior level is not about programming prowess and knowledge of the language. There's much more to software development, and a senior dev should be able to take more responsibility. A programmer might be an absolute Python guru, but not be fit to take a leading role right now.

9:11 PM

If they've used Mongo, but didn't have a DR/backup, even though you sort-of abstract that part away from devs, do you hold it against them?

user41796

@AaronHall Can I hold it against them that they've used Mongo and can't tell me why?

a lot of language have bits and pieces you're better off not knowing anyway, I wouldn't be able to tell you any of the nuances of with because sane people don't touch that keyword

I assumed he knew why he was using it

still worth asking

I'd be more interested in whether or not they cared about the existence of DR/backup and the appropriate use-cases.

Would you rather hire a C programmer that hadn't heard of goto, or one that used it often?

9:14 PM

What languages have a finally that is guaranteed to run no matter what?

None. The machine could be hit by an asteroid before it executes.

Miguel van de Laar

@PhilLello I was just about to say something similar :P

ok, barring failure of the language itself

I don't think any languages have a guaranteed finally, the languages with deterministic cleanup are ones that require you to declare the cleanup functions in advance (C++ destructors, Go's panic/recover stuff, C#'s using/IDisposable)

user41796

@PhilLello neither

9:16 PM

aha, Python's try/except/[else/finally] or try/finally both have a finally that is guaranteed by the language to run.

ah, never mind then

does it guarantee when it runs?

user41796

@AaronHall Not necessarily. The OS can always preempt an application and stop it dead.

before exiting the scope

yeah, but that's kills the language, so any guarantees by the language are off the table

the phrase you're looking for is "undefined behavior"

finally is not taxes nor death so therefore it is not guarenteed

9:19 PM

def fn():
    try:
        return foo()
    finally:
        return bar()

@Ixrec yes, of course. "try: maybe() catch: handler() finally: always()" will run maybe(); handler(); always() in case of an exception or maybe(); always(). Deterministic destructors are not in any way special, except that this final state transition is encapsulated inside an object rather than requiring the user programmer to always remember it.

ok, so in Python, foo is executed, but then before returning the value from foo(), bar is executed and the value from bar() is returned, preempting the return of foo()

@amon admittedly when I think "destructor" I think of a function associated with an object/data type that gets used in any context objects of that type appear, but yeah that makes sense

If bar loops forever so it never completes, would you consider finally to have run?

Or recurses infinately so the stack overflows

if a destructor throws, and no one terminates the program, is it still undefined?

9:22 PM

@Ixrec C#'s finalizers are guaranteed to execute at a non-deterministic time barring machine failure; also the try-catch-finally is the same so long as you put the finally there - though that finally is deterministic..

normally we just ignore that stuff

If you raise an exception in finally that exception will propagate to the top of the program and the program will exit if you do not catch the exception

@AaronHall if you implement a finalizer in C#, it will be executed before the program terminates in the scenario you described

There's also the atexit module which I think is semantically similar to C atexit.

Anyways, what I'm hearing is that most languages don't have a finally, but C# does.

There you fo then. If the exception is raised before the all the statements in finally complete, then arguably finally isn't run. Depends if you define run as "run to completion" or "start execution".

9:24 PM

does Java then also have a finally?

C# finalizers are an interesting ball of wax. So long as the .NET runtime is still running the show - it will guarantee finalizers are all executed at some point between object instantiation and process exit, even in the case of exit due to serious program failure. Unless that program failure is the sort that explodes the hosting VM (which would be something like an OS-level failure)

@AaronHall Java is the one with the infamous "may never run at all" finally

C++ doesn't though?

@AaronHall most languages with try/catch do have a finally clause. As always, Python is not special. However, a throw/try/catch exception system isn't quite universal, see Go for a counter-example

C++ has destructors, so it's never wanted or needed a finally

Miguel van de Laar

9:25 PM

@JimmyHoffa True, with some exceptions, like the notorious OutOfMemoryException (plus a few others)

If I understand C# finalizers, then you could get the same behaviour on POSIX with signal handlers and glue logic.

going outside the language would be cheating

@MiguelvandeLaar the OOM and stackoverflow exceptions are special - but do those actually explode the .NET runtime to the point that before exiting, the finalizer thread won't run? Not saying finalizers will succeed, but I would think the finalizer thread would kick off... OOM is an interesting thought though

@PhilLello I don't think you understand C# finalizers then. They're run by the VM as a part of the GC. To have the same thing you really have to be running in a VM to begin with

Miguel van de Laar

@JimmyHoffa They don't explode the .NET runtime, but you are very limited in what you can accomplish in the finally. In practice most likely you would trigger the same exception again rather than accomplish what is intended.

@JimmyHoffa That's fair enough, I've never used C# and was infering from other comments.

9:29 PM

@MiguelvandeLaar I'm not talking about a finally - those don't execute in the event of a SO or OOM exception. I'm talking about finalizers which are a totally different thing

On a not very related note, I'm sure I saw an error message in some source code along the lines of "Out of memory, not even enough to show this message"

@PhilLello I detail finalization here:

113

A: When is it a good idea to force garbage collection?

You really can't make blanket statements about appropriate way to use all GC implementations. They vary wildly. So I'll speak to the .NET one which you originally referred to. You must know the behaviour of the GC pretty intimately to do this with any logic or reason. The only advice on collect...

At the bottom of my answer I go over how finalization works. Frankly I'm not certain if an SO or OOM would halt the runtime before GC cleaned up...

of course, when possible it's best to avoid the kind of code that requires cleanup in the first place

most managed languages have relatively little of that to begin with

Well yes. But that's like saying you don't need to free memory or close file handles before exiting a process. Factually correct, but it just feels wrong

@Ixrec read my answer there to get an idea for it - I think I make it clear that it's an extremely uncommon scenario where you would actually need/want such cleanup code. There's very good reasons not to do more than the very rare scenarios of it as well.

9:33 PM

@PhilLello I mean the freeing of memory is done by the VM in such languages so it's not even feeling wrong, it's just not needed

if you need to open files or databases from those languages then yeah that's the part that will require cleanup

Hmm. Anyway, tiredness is overruling my common sense now, so I'm going AFK.

I'm not sure how common this pattern is, but where I work the library that lets us access databases from JS does so by making us pass a callback function (that takes the db handle as an argument), so the database transaction begins before it gets called and ends after it returns (or if it returns a promise, after said promise resolves) which gives us pretty good hard-to-screw-up cleanup semantics

user55340

Btw, if you ever read about the life cycle of the fig wasp, you'll never touch another fig newton again.

Continuation-passing style

In functional programming, continuation-passing style (CPS) is a style of programming in which control is passed explicitly in the form of a continuation. This is contrasted with direct style, which is the usual style of programming. Gerald Jay Sussman and Guy L. Steele, Jr. coined the phrase in AI Memo 349 (1975), which sets out the first version of the Scheme programming language. John C. Reynolds gives a detailed account of the numerous discoveries of continuations. A function written in continuation-passing style takes an extra argument: an explicit "continuation" i.e. a function of one argument...

that's what Node.JS is entirely built around

@MichaelT Let's face it, biology is yucky sticky stuff - best not to think about where food comes from.

user55340

9:42 PM

(fig wasps are really neat though)

@JimmyHoffa oooooh, so that's what that phrase means

user55340

@PhilLello Biology is great... just the "ok, going to think about eating that."

@JimmyHoffa Yeah, but isn't that just a verbose way of describing callbacks?

Not that you're responsible for what someone else wrote in 1975

since my comment was "we use a callback" in so many words, I'm guessing that's exactly his intention

@Ixrec Given higher-order functions, I can implement any control flow, which is really neat if the language doesn't support that built-in. My favourite helper is with = function(x, f) { f(x); return x;} which attaches side effects to a value, really useful for initialization in an expression context: y = with(new Thing(), x -> { x.setFoo(42); }).doSomething(). Scoped resource use as you described is another common pattern, e.g. used by Ruby for opening files.

9:49 PM

@PhilLello callback and continuation are relatively synonymous terms, but the "continuation passing style" is a little greater meaning in regards to suggesting that is done with more frequency- thus "style" indicating it's something you do consistently in a given set of scenarios. Also it suggests it's completely explicit.

come to think of it, promises are a form of CPS, aren't they?

Callbacks are often times done as a "when you're done, come back here" or "when this happens, do this", continuation refers to you writing code that says "do this - and then continue after that with this"

@Ixrec in a sense... again continuation passing is all about writing code that says "do this, then continue with this" like getPerson(personId, function(person) { /* then continue on with this */ })

Continuations are a bit more general than callbacks. A callback returns to the calling function. A continuation represents the location and context where a function should return to, which might be totally unrelated. We can use closures as continuations iff the language supports tail calls.

Interestingly, one of the earliest descriptions of OOP described objects as continuations, with the object state being a continuation. A method invocation would be performed in this context, creating a new context that can be “picked up” later from another method.

I guess (and I apologise for the BASIC terminology) CPS suggests a goto rather than a gosub.

with promises you're saying var promise = getPerson(personId); promise.success(function(person) { /* on success do this */ }); <-- not the same as handing in a continuation explicitly necessarily..

semantically, they're all based around the same ideas really

9:54 PM

yeah it's all getting a bit fuzzy

err aye

Feels a bit state-machiney

my typers are the broke.

either way, when you hand out an explicit "and then, continue with this" <-- that's a continuation.

when you attach a callback to .onClick that's typically not called a continuation

yeah, that makes sense, as you're not asking for anything to happen right now, just wiring things up for later (or maybe never)

I normally call those "handlers" instead of "callbacks", probably for that reason

@Ixrec same

9:59 PM

@JimmyHoffa We're probably both right. Closures have continuation-like properties. I can implement CPS via closures + tailcall. So they're somewhat equivalent? Of course, a call-with-continuation never directly returns, it just picks up another continuation, which is not equivalent to calling a callback.

not getting the state machine comment though, this CPS stuff is normally expressing a linear control flow, or at most a DAG of control flow, while proper state machines can have cycles and other stuff that requires preemptive wiring rather than immediately calling with callbacks

@amon exactly, it's that never-directly-returns scenario that forces the style of continuation passing, this is where Node.JS lives

ah, that makes more sense, promises are definitely not CPS then

var fooFix = function(f){return function(g) { return g < 1 ? g : f(f)(g - 1); }};
var foo = fooFix(fooFix);

^^ something I do in JavaScript which... I really probably shouldn't.

It just feels better than making foo call foo(g-1) when I want recursion in JavaScript

I'm having great difficulty making sense of that

10:05 PM

whenever I want to make a recursive function in JavaScript I typically do that. I should be ashamed.

that is definitely not normal

@Ixrec I blame Haskell. It feels cleaner than normal recursion because I always feel like in the definition of foo making a direct call to foo is referencing an ambiguous and replaceable scope.

(I never do that in Haskell mind you)

fooFix(fooFix) commands a binding for f in the closure of my function body that cannot be altered

are you talking about what the receiver/implicit this object gets bound to?

var foo = function(g) { return g < 1 ? g : foo(g-1) }
foo.call({foo: console.log }, 10)

JS is insane.

10:11 PM

@Ixrec in my fooFix(fooFix) <-- foo is now a closure with which it's tail-call is irreplaceable, in the example above, I have replaced the tail call however

I don't think 10.foo() is a real method

sorry, I got the params backwards

:P

smartarse

user55340

@Ixrec In ruby it is...

@amon yeah, it's one of those "I trust everything I write in it, but nothing anybody else writes" languages.

it can be nice, and I like writing it for me, but the way everyone else does things in it I find scary

@JimmyHoffa I'm trying that in my browser console now, it's not doing anything

10:13 PM

@Ixrec what exactly are you doing?

I'm pretty sure the first argument of call() only affects what this is inside the function, it doesn't redefine foo itself

> foo(10)
0
> foo.call({foo: function(x) { return x + 2; } }, 10)
0

@Ixrec that appears to be so..

either way, I do things like I did above just to make semantics explicit and guaranteed where the alternatives have so many ambiguities...

> var foo = function(x) { return this.private + x; }
undefined
> foo(10)
NaN
> foo.call({ private: 42 }, 10)
52

yeah, call() only changes what this is

@Ixrec true, but inside the scope of foo -> isn't it's references to foo referencing the one in this ?

um, only if you write this.foo ?

10:16 PM

I mean.. this.foo and foo are the same thing unless you swap this with call but, if they're the same thing before the swap...why aren't they the same thing after you swap?

and this does not have a foo member anyway

contrary to the thing you just said which makes no sense

While .call() doesn't seem to work, the problem still is extreme late binding where variables might just be redefined – it's also on top of my Python hatelist. Salvation can only be found in referential transparency.

yep, this and all it's semantics are thus too confusing and wholly avoidable for me.

statefulness in general is worth avoiding

I certainly can't imagine writing a (maintainable) recursive function that references this

though I do think you're completely misunderstanding this and it's nowhere near as insane as you seem to think

@Ixrec yeah, thus why I write mine to only reference parameters.

@Ixrec I understand this in terms of function bla(foo) { this.stuff = things; }; new bla(arr);

10:21 PM

constructors are special, yeah

but that's a different semantic than other closures this I believe... the whole thing is strange to me and relies on a variety of scoping rules and scenarios that seem more than what's worth having to reason through

the basic rule is: whenever you call object.method(arguments), then inside of method, this will be object

thus why I just never ever use this and call it a day. I write constructos as var createThing = function(foo) { return { stuff: things } }; var wha = createThing(arr);

when you use the new operator, you're effectively creating a brand new object out of thin air and then calling the constructor on that new object

that's really it

yeah, I get that, there's still just too many rules to try reasoning about when you get into larger scales and more code... my approach is utterly explicit and avoids ever having to think about it

10:24 PM

yes, in many cases it's better to use a factory function like that

@Ixrec that's what they call them in JS? Factory functions? Never heard it; that works though.

I have no idea if that's the "standard" term, but it is a function that produces an object, despite not being the constructor of that class of objects, so that seems to fit typical definitions of "factory function"

there's also Object.create(), which is particularly nice since it makes the prototype explicit (including the ability to set a null prototype, which means no random unwanted properties if that sort of thing bothers you), though it does mean more lines of code so I wouldn't use that unless I was writing a library or something

incidentally, when I do use this, it's always when a class' constructor and all of its methods are defined in a single file; I agree it would be insane to try doing anything more complex than that

these days that's usually for classes which manage UI widgets, and therefore need to be stateful

@JimmyHoffa I'm not seeing a real problem being solved here. Other than the "maintainers will almost certainly thank me for recursing via fixed point combinators" factor.

it's annoying that the starred comment about JS being insane was directed at a simple factual inaccuracy, instead of one of the many genuine (though easily avoidable) insanities like {} + {} yielding NaN

you've gotta watch out for the star-bush. an ambush... of stars!

10:38 PM

@psr as I mentioned; I should be ashamed of writing such things. The benefit is only to me: It's utterly explicit what will be called because it came in through a parameter thus it's a known local and I need to expend no mental energy assessing what in the scope resolution it's finding it's way to. It's only clearer to me, and certainly less clear to anyone else than the alternatives..

@psr map is truly black voodoo magic, we all know this. Couldn't be more obvious.

I still don't see how that clarifies anything when the recursive function never references this to begin with

the inner function already has its own scope, because it's a function, so it's not like there can be any ambiguities unless you reference something defined outside the function

@Ixrec var foo = function(g) { return g < 1 ? g : foo(g) } <-- I have to decide what it's resolving foo to: is it itself, or something in a different scope? Probably itself, but I find the JavaScript scope resolution rules far more than I care to wrap my head around most the time

@Ixrec foo is defined outside of the function though - that's the ambiguity to me

you could always skip the variable by using a named function expression

function foo(n) { return (n < 1) ? n : foo(n-1) + n; }

@Ixrec that makes it absolutely no more clear.. foo is still something defined outside the scope of foo and frankly I only understand the function name() syntax where it pertains to constructors. I stay away from vast portions of JavaScript because there's so damned much that can be did, so it's not always clear what all those other areas will do. Like I've said before, I just treat JavaScript like untyped lambda calculus... keep everything local and referentially transparent

I quite like the language and understand it well in the scope of the very narrow space I stick to. Outside of the narrow space of JavaScript I actually use, I never really bothered to wrap my head around it all. It get's very weird very quickly...

hm, it's true that you could still do var x = foo; foo = someOtherFunc; and then x(10) doesn't do what it should

then again you can still do the same thing with fooFix

so none of that matters

10:45 PM

@Ixrec that's actually not true, is it?

@JimmyHoffa well, the weird parts are best avoided whether or not one is a functional guru, that's nothing unusual

@JimmyHoffa I just checked in the console, if you do that then x(10) will "recursively" call someOtherFunc

which again is just as doable with your foo/fooFix version so that was a pointless tangent on my part

@Ixrec weird. Anyway, in my example of fooFix you can't unbind the f tied in the closure

there's still nothing prevent me from doing fooFix = someOtherFunc

unless you get ES6 const involved, which again makes both versions "safe"

var foo = fooFix(fooFix);
undefined
foo(10);
0
fooFix = console.log
log() { [native code] }
foo(10);
0

f is bound to the specific instance of fooFix passed into the fooFix function, so foo is a closure with a hard bound f

using console.log as your test function is not a good idea

ah, ok I see what you mean, it'd have to be foo = whatever

10:49 PM

@Ixrec that wouldn't change the definition of fooFix though or the behaviour of the function fooFix(fooFix)

foo doesn't call foo ever

see, it's the explicitness that makes me feel safer doing it my way and as though the behaviour is guaranteed and super clear - though agreeably absolutely everyone else who looks at it will think I'm off my nut and wonder 'the hell I'm doing

I think now I'm seeing why your version could be considered more explicit

I have to zygomorph my brain to see it but it is there

@JimmyHoffa How in a recursive call to Foo would scope resolution get set to anything else? Is there some case where this can actually happen?

like I said, I treat JavaScript like untyped lambda calculus... it becomes safe and easy to work with when you get used to looking at it like that

@psr I think so? Scope resolution in JavaScript is an absolute mess.

scope is really simple in JS...it's just function scope instead of block scope

which is not the most intuitive thing ever, but it's no less simple than other languages

function wha() {
var foo = console.log;
this.foo = function(g) { return g < 1 ? g : foo(g-1) };
}


undefined
var arr = new wha();
undefined
arr.foo(10);
VM2835:4 Uncaught TypeError: Illegal invocation(…)

I don't even know how that caused an error?

user55340

10:55 PM

Secretary problem

The secretary problem is a famous problem of optimal stopping theory. The problem has been studied extensively in the fields of applied probability, statistics, and decision theory. It is also known as the marriage problem, the sultan's dowry problem, the fussy suitor problem, the googol game, and the best choice problem. The basic form of the problem is the following: imagine an administrator willing to hire the best secretary out of rankable applicants for a position. The applicants are interviewed one by one in random order. A decision about each particular applicant is to be made immediately...

function foo(n) { var foo=1; return (n<1) ? n : foo(n-1) +n;} console.log(foo(10));

That does err out because the inner foo messes up the scope.

@Ixrec any ideas how my construction above caused an error?

@psr in my construction above, which foo is supposed to get called? (I really am not aware.. as I said, I just stay away from those parts of JS altogether so I don't actually know how they're supposed to work)

I haven't figured it out yet, but this is an example of going out of one's way to break things and not the sort of problem that would arise accidentally

@Ixrec you've never seen someone try to create 2 variables with the same name on accident before? Someone wants to implement a getPerson function that does one thing, then later on somebody decides they need to getPerson with a different set of facilities...

even I've done stuff like that. create a personId in one scope then make it in another nested scope before realizing I'm stomping things... which is why I stick to parameters. Their local scope overrides everything.

@JimmyHoffa Tried it in node and it printed 9 and returned undefined.

11:01 PM

@JimmyHoffa in the same class? no, unless the class is so absurdly huge it already needs breaking up

(which is actually what I would have guessed).

again, I agree that relying solely on referentially transparent functions makes things a lot simpler, and often there's no need for this at all

@psr same, I would have guessed as much too. The illegal thing may be just my mess in my current console heh

@Ixrec yeah, often times keeping things smaller and cleaner is the solution people reach for and it's a good one for sure.

@JimmyHoffa oh duh, you did console.log without .bind(console)

Abhishek Bhatia

I read in a book "scripts that don't start a subshell". I don't understand this. Ain't all scripts run in a non-interactive shell?

11:03 PM

this is why not to use console.log as your go-to example function!

@Ixrec haha :D

since it doesn't exist in production code, any "quick tests" involving it get mired in stupidity like this no one is familiar with because it's completely irrelevant to real code

and, it's a function that (internally) relies on this being correct

either way. Humbug to all of it. I'll continue to occasionally fix my recursion in JS just to make myself feel better that I know exactly what it's doing, and likely occasionally throw caution to the wind and just use the direct recursion.. whatever. No one ever looks at my code anyways.

JS is just an interpreter for an odd variant of untyped lambda calculus. Yeps. I'm sticking to that theory.

lol

@MichaelT pen me in for definitely not the person who should write the blog article about writing reasonable code

user55340

11:09 PM

@JimmyHoffa heh... I'm still waiting for you to do a take on 5 languages to learn.

user55340

Or maybe kids and code (if you have any insight into that)

user55340

Or maybe monads with the restriction of simple writer?

hmm... of the top of my head.. C for basic imperative logic concepts with nearly no syntactic overhead that gives a good mental model for how a computer actually functions. LISP to learn to read and think in post-fix and create and pass around functions. SML to learn about a type system that requires thinking in a declarative fashion and pushes you to come up with solutions in ways other languages don't push you to. Debating between Prolog and SQL for thinking in terms of sets and constraints? and the 5th perhaps Java to know the lingua franca of modern industry development concepts.

I'd assume SQL since the connection to databases makes it significantly more useful than Prolog for most purposes

For me it's all about plotting points that are as far apart from each other as possible to provide as many mental models for solutions as possible. In each language you can implement solutions you learned from the others, which is why it's valuable to have concepts from each language as it provides more available models for solving problems.

11:18 PM

yeah, once you have that kind of breadth you can pick up pretty much any other language as needed

@Ixrec yeah, I'm thinking so, though it doesn't teach the constraint concepts as clearly, but it's a hell of a lot more useful and it still does teach them.

it's likely I don't know Prolog well enough to tell what you're getting at there

@Ixrec I'm thinking more: Given a problem to solve, you have many ideas about how to solve it, as opposed to only having the proscribed Java solution in mind for instance - where each problem may be better solved by other approaches than are typical

@Ixrec I don't know it greatly either, but what I've done playing with it, you create the simplest pieces of data (facts) and the constraints you then create to query are completely based on nothing but those facts. It's just syntactically super clean compared to SQL and has no structural demands like an RDBMS

11:45 PM

likes(john, apple).
has(jean, apple).
should_make_friends_with(X, Y, Z) :- likes(X, Z) , has(Y, Z).

?- should_make_friends_with(john, PERSON, FOR).
> PERSON = jean,
> FOR = apple

user15026

I want an apple now.

^^ creating data and querying it via constraints is much cleaner and simpler than in SQL where you have to create a table, describe the whole thing, and have the whole RDBMS piece along with the set logic. Prolog is only the set logic without any of the DB concerns.

But I would probably go with SQL for my language people should learn because it's vastly more useful and the RDBMS concerns such as transactions are important as well as the set and constraint logics

I associate "set logic" far more with SQL than Prolog, since SQL actually does operate fundamentally in sets of rows while Prolog is fundamentally always working with one (potentially very complex) query/statement

does Prolog even have any of that built-in or do you have to write the implementation of union/intersection/etc yourself?

@Ixrec perhaps it's better to think of it in terms of vectors than sets? not altogether dissimilar though

vector as in a one-dimensional ordered sequence?

11:58 PM

likes(john, apple).
likes(john, chocolate).
likes(john, mungecake).
has(jean, apple).
has(joe, chocolate).
has(jira, mungecake).
should_make_friends_with(X, Y, Z) :- likes(X, Z) , has(Y, Z).

?- should_make_friends_with(john, PERSON, FOR).
> FOR = apple,
> PERSON = jean
> FOR = chocolate,
> PERSON = joe
> FOR = mungecake,
> PERSON = jira

The queries return entire sets that fulfill the constraints

oooh, I completely forgot they did that

not sure how that's not set logic? It's a bit different perhaps than SQL, but...

mmm mungecake...

nvm for some reason I forgot it could produce multiple outputs

« first day (2009 days earlier) ← previous day next day → last day (2995 days later) »

Transcript for

Mar '164

The Whiteboard

General Discussion for softwareengineering.stackexchange.com P...

coffee-day horror-stories monads my-code-is-compiling scotch the-other-monitor

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

site design / logo © 2024 Stack Exchange Inc; legal

mobile