p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

Max Facetime: Apr 18, 2009

tef posted:

and it isn't turning off type checking , it's deferring type errors to runtime

they cite something for java, DuctileJ, which they say goes over the rationale in more detail

http://www.cs.washington.edu/homes/mernst/pubs/ductile-icse2011.pdf

kids today, can't even read the abstract let alone the title of a paper.

this is a pretty bad paper

their 'developer' that they quote sounds like a first year student:

In converting his prototypes to type-correct code, the developer discovered that he had unintentionally called private or protected methods from code that did not have access to those methods. He was glad that he was not using the stock Java compiler, which he felt would have distracted him from his prototyping task to determine the correct way to accomplish the desired functionality.

getting the results they wanted ...

The developer investigated three approaches. A type-driven manual refactoring required 24 code changes to make the test case pass. A type- driven refactoring with Eclipse support required one Eclipse refactoring, then 16 manual edits (a few of them tricky, as described below) to make the test case pass. A manual refactoring using DuctileJ required only the 3 key changes before the test case passed.

... by using the wrong refactoring tool

The developer instructed Eclipse to change the signature of the Figure.containsPoint method by removing the x and y parameters, adding a java.awt.Point p parameter, and using new java.awt.Point(x, y) as the default argument for calls.

they briefly entertain the idea of the correct refactoring (Introduce Parameter Object) existing:

While this case study is simple, and could be better supported by improved refactoring tools in the Eclipse IDE,

they decide to redefine refactoring to include any rewrite as long as you swear not to break anything:

developers frequently perform refactorings that are even more complex and must be done with limited or no automated refactoring support [27].

# ? Mar 7, 2013 06:08

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 05:16

Zombywuf: Mar 29, 2008

I prefer having my runtime errors happen at compile time. Gets them out of the way early.

# ? Mar 7, 2013 11:36

Workaday Wizard: Oct 23, 2009; by Pragmatica

i've been doing some euler problems with haskell and it's so easy it feels liek cheating but why the gently caress is there an ambiguity between zip from prelude and zip from Data.Sequence the fuckers do not share a single common parameter type ughhhhhhhhhhhhhh

# ? Mar 7, 2013 11:59

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

i dont make runtime errors all the time

but when i do, i make them at compile time

# ? Mar 7, 2013 12:24

Max Facetime: Apr 18, 2009

Win8 Hetro Experie posted:

developers frequently perform refactorings that are even more complex and must be done with limited or no automated refactoring support [27].

the paper they referenced http://people.engr.ncsu.edu/ermurph3/papers/tse11a.pdf

which refactoring tools people used:

now what would these statistics look like for a dynamically typed language, oh wait refactoring dynamically typed code would be like playing yahtzee with marbles :laugh:

# ? Mar 7, 2013 13:44

qntm: Jun 17, 2009

xslt combines the twin powerhouses of for loops and non-variable variables with the terse readability of xml

# ? Mar 7, 2013 13:45

Max Facetime: Apr 18, 2009

holy poo poo that's a good paper, some quotes:

Ideally, a programmer will always use a refactoring tool if one is available, because automated refactorings are theoretically faster and less error-prone than manual refactorings. However, in one survey of 16 students, only 2 reported having used refactoring tools, and even then only 20% and 60% of the time [10]. In another survey of 112 agile enthusiasts, we found that the developers reported refactoring with a tool a median of 68% of the time [10].

Consider that refactoring tools are often used repeatedly (Section 3.2), and that programmers often do not conﬁgure refactoring tools (Section 3.3). For the toolsmith, this means that conﬁguration-less refactoring tools, which have recently seen increasing support in Eclipse and other environments, will suit the majority of, but not all, refactoring situations.

We provided developers with several examples of a refactoring that they themselves performed with a tool in one case but without a tool in another. We then asked them to explain this behavior. From their responses, we identiﬁed three factors� awareness, opportunity, and trust �and two issues with tool workﬂow�touch points and disrupted ﬂow�that may limit tool usage.

As an example, one developer was not familiar with how the tools for the INLINE refactoring worked despite being an experienced developer. Similarly, one toolsmith described awareness problems occuring in the following scenario:

� �I already know exactly how I want the code to look like.

� Because of that, my hands start doing copy-paste and the simple editing without my active control.

� After a few seconds, I realize that this would have been easier to do with a refactoring [tool].

� But since I already started performing it manually, I just ﬁnish it and continue.�

(toolsmiths are the eclipse developers who make the refactoring tools)

# ? Mar 7, 2013 14:28

Dr. Honked: Jan 9, 2011; eat it you slaaaaaaag

i just choked on my own scoff

# ? Mar 7, 2013 14:54

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

Dr. Honked posted:

i just choked on my own scoff

should have been a cockroach

# ? Mar 7, 2013 15:27

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

Notorious b.s.d. posted:

should have been a cockroach

how dare they sully the image of the noble squirrel

# ? Mar 7, 2013 16:23

AppleCobbler: Feb 8, 2003; remember that time I was just chilling out and definitely not having a massive meltdown? right guys? guys???

trex eaterofcadrs posted:

how dare they sully the image of the noble squirrel

# ? Mar 7, 2013 17:53

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

Win8 Hetro Experie posted:

the paper they referenced http://people.engr.ncsu.edu/ermurph3/papers/tse11a.pdf

which refactoring tools people used:

now what would these statistics look like for a dynamically typed language, oh wait refactoring dynamically typed code would be like playing yahtzee with marbles

congrats on being the fastest at reshuffling your class hierarchies

# ? Mar 7, 2013 19:21

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

trex eaterofcadrs posted:

how dare they sully the image of the noble squirrel

like roaches, squirrels also eat their own poop

maybe that's the inspiration and i maligned their cover artists needlessly

# ? Mar 8, 2013 02:31

Opinion Haver: Apr 9, 2007

Shinku ABOOKEN posted:

i've been doing some euler problems with haskell and it's so easy it feels liek cheating but why the gently caress is there an ambiguity between zip from prelude and zip from Data.Sequence the fuckers do not share a single common parameter type ughhhhhhhhhhhhhh

the idea of type-directed name resolution has been floated before, people don't like it for reasons i don't remember

# ? Mar 8, 2013 04:23

abraham linksys: Sep 6, 2010

clojurescript day 3 or 4 or whatever:

reactive/event-driven functional programming is weird. it's something that requires mutable state, and for that matter a global mutable state, in most cases. hell, i'd generalize to "making a UI-driven functional program" is weird because a UI-driven program inherently needs events and global mutable state.

clojurescript/clojure, of course, have many mutable constructs. you can create atoms from any date types, which are just mutable versions of those types, and can even bind event listeners ("watchers") to those atoms. but it just feels wrong in a lot of ways

i made a dom binding library, where you can set properties, bind them to dom elements, and then have them update automatically when the property changes. it works by having a state atom map that looks something like

code:

{:color {:content "purple"
         :bindings {:element <some dom node>
                    :type :content or :class
                    :transform fn [value] ()}}}

for as many properties (i.e. ":color") and bindings on those properties as needed. so there's various functions that work on this, and they all take this bindings map as their first argument. so you end up doing stuff like:

code:

(let [bike-shed (atom (dom-binding/create-dom-map))
      binded-element (.querySelector js/document "#bindable")]
   (swap! bike-shed dom-binding/assoc-property! :color "purple")
   (swap! bike-shed dom-binding/add-dom-bind! :color :#bindable)
   (swap! bike-shed dom-binding/assoc-property! :color "red")

or alternatively, with the fancy -> macro:

code:

(let [bike-shed (atom (dom-binding/create-dom-map))
      binded-element (.querySelector js/document "#bindable")]
  (reset! bike-shed
          (-> @bike-shed
              (dom-binding/assoc-property! :color "purple")
              (dom-binding/add-dom-bind! :color :#bindable)
              (dom-binding/assoc-property! :color "red")))

of course, it doesn't have to be an atom - you could simply nest your functions or use the -> macro and define bike-shed all at once and never worry about mutating it. but if you have any sort of event-driven structure, you'll need to store it for later use.

there's alternate ways i could have implemented this library, to be fair. i could have simply defined various properties as individual atoms and then added watchers (event listeners) to update the dom. if you do that, of course, then you're dealing with a bunch more state than just one map (though at the same time you could at least use the usual swap!/reset! on individual items instead of the kind of weird assoc-property on a map).

no matter how you implement it, it will always be varying degrees of impure, and varying degrees of awkward. i think that there's nothing inherently wrong with impure functions in a functional language, but in clojurescript, it's constant any time you're dealing with the dom, and you begin to wonder why you're bothering with a functional language in this scenario.

the only thing you can really do is try to abstract it away as much as possible - which ultimately is what FRP is, i guess, an abstraction over event-driven programming (where you're dealing with "streams" and whatnot instead of individual events). still, FRP with dom events isn't truly possible, as far as i can tell, because the dom is based on discrete events and can't really be done as a stream. like, elm handles things like mouse input with a stream by just having an event loop that polls however many times a second, instead of "true" event listening.

the tldr of this ridiculously long post that i probably should add grammar to and then blog somewhere is that reactive functional programming doesn't work in the way you want it to in the browser, unfortunately, and it makes clojurescript much less attractive in many ways, and i really want to hear people's rebuttals because i'm hoping that there's some large component that i'm completely missing that makes this irrelevant

# ? Mar 8, 2013 04:51

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

object.watch really should have made it into the ecmascript spec

# ? Mar 8, 2013 04:54

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

abraham linksys posted:

clojurescript day 3 or 4 or whatever:

reactive/event-driven functional programming is weird. it's something that requires mutable state, and for that matter a global mutable state, in most cases. hell, i'd generalize to "making a UI-driven functional program" is weird because a UI-driven program inherently needs events and global mutable state.

clojurescript/clojure, of course, have many mutable constructs. you can create atoms from any date types, which are just mutable versions of those types, and can even bind event listeners ("watchers") to those atoms. but it just feels wrong in a lot of ways

i made a dom binding library, where you can set properties, bind them to dom elements, and then have them update automatically when the property changes. it works by having a state atom map that looks something like
code:
{:color {:content "purple"
         :bindings {:element <some dom node>
                    :type :content or :class
                    :transform fn [value] ()}}}
for as many properties (i.e. ":color") and bindings on those properties as needed. so there's various functions that work on this, and they all take this bindings map as their first argument. so you end up doing stuff like:
code:
(let [bike-shed (atom (dom-binding/create-dom-map))
      binded-element (.querySelector js/document "#bindable")]
   (swap! bike-shed dom-binding/assoc-property! :color "purple")
   (swap! bike-shed dom-binding/add-dom-bind! :color :#bindable)
   (swap! bike-shed dom-binding/assoc-property! :color "red")
or alternatively, with the fancy -> macro:
code:
(let [bike-shed (atom (dom-binding/create-dom-map))
      binded-element (.querySelector js/document "#bindable")]
  (reset! bike-shed
          (-> @bike-shed
              (dom-binding/assoc-property! :color "purple")
              (dom-binding/add-dom-bind! :color :#bindable)
              (dom-binding/assoc-property! :color "red")))
of course, it doesn't have to be an atom - you could simply nest your functions or use the -> macro and define bike-shed all at once and never worry about mutating it. but if you have any sort of event-driven structure, you'll need to store it for later use.

there's alternate ways i could have implemented this library, to be fair. i could have simply defined various properties as individual atoms and then added watchers (event listeners) to update the dom. if you do that, of course, then you're dealing with a bunch more state than just one map (though at the same time you could at least use the usual swap!/reset! on individual items instead of the kind of weird assoc-property on a map).

no matter how you implement it, it will always be varying degrees of impure, and varying degrees of awkward. i think that there's nothing inherently wrong with impure functions in a functional language, but in clojurescript, it's constant any time you're dealing with the dom, and you begin to wonder why you're bothering with a functional language in this scenario.

the only thing you can really do is try to abstract it away as much as possible - which ultimately is what FRP is, i guess, an abstraction over event-driven programming (where you're dealing with "streams" and whatnot instead of individual events). still, FRP with dom events isn't truly possible, as far as i can tell, because the dom is based on discrete events and can't really be done as a stream. like, elm handles things like mouse input with a stream by just having an event loop that polls however many times a second, instead of "true" event listening.

the tldr of this ridiculously long post that i probably should add grammar to and then blog somewhere is that reactive functional programming doesn't work in the way you want it to in the browser, unfortunately, and it makes clojurescript much less attractive in many ways, and i really want to hear people's rebuttals because i'm hoping that there's some large component that i'm completely missing that makes this irrelevant

man i'm glad you're getting out there but holy poo poo you are doing it wrong

i saw a dude at groupon make a multiplayer clojurescript version of nethack in less characters than what you posted

# ? Mar 8, 2013 05:23

Jonny 290: May 5, 2005; [ASK] me about OS/2 Warp

ilu anvol but what the gently caress is that gobbledygook babble language up there.

son do i need to snail mail you K&R in dead tree format or god forbid the camel book

# ? Mar 8, 2013 05:41

Jonny 290: May 5, 2005; [ASK] me about OS/2 Warp

oh man its a lispy thing. neat

ok yah i cant write this poo poo but i dont think you're doing it quite right up there

# ? Mar 8, 2013 05:44

abraham linksys: Sep 6, 2010

i didn't either but i had a clojure diehard look over it and he thought it looked okay, though he didn't know a lot about clojurescript specifically

if i reimplemented it i'd do it as separate atoms for each property and then have watchers as the bindings on them, which would be significantly more elegant than having to use assoc-property! on the map, though i bet internally adding bindings will look ugly as hell. in fact that may be a macro thing, and i'd like to learn how to write macros, so i'll probably reimplement that soon

but while in this case there's a better way to do it, the concept of passing a dereferenced version of your mutable state to a function, then changing that state to the result of the function (which is what the swap! function does) is really common in clojurescript and just feels almost like an abstracted version of object-oriented programming

# ? Mar 8, 2013 05:49

JawnV6: Jul 4, 2004; So hot ...

abraham linksys posted:

clojurescript day 3 or 4 or whatever:

ive spent years in languages

# ? Mar 8, 2013 07:50

Jonny 290: May 5, 2005; [ASK] me about OS/2 Warp

JawnV6 posted:

ive spent years in languages

exactly, you're old and set in your ways
AGILE

# ? Mar 8, 2013 15:10

Police Academy III: Nov 4, 2011

abraham linksys posted:

code:

(let [bike-shed (atom (dom-binding/create-dom-map))
      binded-element (.querySelector js/document "#bindable")]
  (reset! bike-shed
          (-> @bike-shed
              (dom-binding/assoc-property! :color "purple")
              (dom-binding/add-dom-bind! :color :#bindable)
              (dom-binding/assoc-property! :color "red")))

idk dick all about DOM stuff, but you really should try to separate the mutable and immutable bits. I'd make pure functions that take and return your dom-map things and then just use swap! with them

edit:

quote:

but while in this case there's a better way to do it, the concept of passing a dereferenced version of your mutable state to a function, then changing that state to the result of the function (which is what the swap! function does) is really common in clojurescript and just feels almost like an abstracted version of object-oriented programming

yeah this, do this. idk what you mean about OOP but the biggest advantage of functional programming imo is not doing super clever map-reduce-filter bs, it's the added simplicity that immutability and pure functions/expressions give you.

Police Academy III fucked around with this message at 19:15 on Mar 8, 2013

# ? Mar 8, 2013 19:09

Max Facetime: Apr 18, 2009

tef posted:

congrats on being the fastest at reshuffling your class hierarchies

I like to think of it as ~exploratory design~

# ? Mar 8, 2013 19:12

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

rotor posted:

object.watch really should have made it into the ecmascript spec

https://gist.github.com/eligrey/384583

# ? Mar 8, 2013 19:40

JawnV6: Jul 4, 2004; So hot ...

i thought i was all clever for coming up with "gisthub" where it's like github for "idea guys" but ive apparently been beaten??

# ? Mar 8, 2013 19:58

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

Win8 Hetro Experie posted:

I like to think of it as ~exploratory design~

this is what the lack of a repl causes

# ? Mar 8, 2013 20:46

SavageMessiah: Jan 28, 2009; Emotionally drained and spookified; Toilet Rascal

abraham linksys posted:

i didn't either but i had a clojure diehard look over it and he thought it looked okay, though he didn't know a lot about clojurescript specifically

if i reimplemented it i'd do it as separate atoms for each property and then have watchers as the bindings on them, which would be significantly more elegant than having to use assoc-property! on the map, though i bet internally adding bindings will look ugly as hell. in fact that may be a macro thing, and i'd like to learn how to write macros, so i'll probably reimplement that soon

but while in this case there's a better way to do it, the concept of passing a dereferenced version of your mutable state to a function, then changing that state to the result of the function (which is what the swap! function does) is really common in clojurescript and just feels almost like an abstracted version of object-oriented programming

why not just put the whole DOM in an atom? https://github.com/drcode/webfui

# ? Mar 8, 2013 22:23

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

heroku's office is pretty nice

# ? Mar 8, 2013 23:05

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

tef posted:

heroku's office is pretty nice

how ergonomic are their chairs?

# ? Mar 8, 2013 23:19

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

no idea, sofa is comfortable

# ? Mar 8, 2013 23:24

abraham linksys: Sep 6, 2010

SavageMessiah posted:

why not just put the whole DOM in an atom? https://github.com/drcode/webfui

i saw that after making it. it's a pretty cool way of doing things.

Police Academy III posted:

idk dick all about DOM stuff, but you really should try to separate the mutable and immutable bits. I'd make pure functions that take and return your dom-map things and then just use swap! with them

that's exactly what i'm doing, actually. it looks weird because those dom functions have exclamation marks on them, but that's because they update the dom, not because they update the scope.

those two examples are identical - both are creating a bike-shed atom, passing the dereferenced (immutable) version of that as the first argument to various functions which return a modified version, and then replacing the atom with the new version.

really the proper way to do this is either webfui or create individual property atoms with watchers updating the dom bound on them, but those options are still really weird compared to regular-rear end javascript!

# ? Mar 9, 2013 02:29

JewKiller 3000: Nov 28, 2006; by Lowtax

i bought a bottle of four roses today and drank some of it. at this time i am hosed up (presently (right now (this minute)))

program in ML or get the gently caress out of my face forever

# ? Mar 9, 2013 06:12

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

JewKiller 3000 posted:

i bought a bottle of four roses today and drank some of it. at this time i am hosed up (presently (right now (this minute)))

program in ML or get the gently caress out of my face forever

standard or moscow

# ? Mar 9, 2013 06:36

JewKiller 3000: Nov 28, 2006; by Lowtax

Carthag posted:

standard or moscow

ocaml tbqh but if you prefer sml i guess that is fine

i don't know anyone who still uses moscow ml!

# ? Mar 9, 2013 06:50

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

JewKiller 3000 posted:

ocaml tbqh but if you prefer sml i guess that is fine

i don't know anyone who still uses moscow ml!

i dont either, i just was taught standard back in 03/04 and i remember there being a moscow variant too. its pretty shameful, i just wanted to fit in

# ? Mar 9, 2013 06:53

JewKiller 3000: Nov 28, 2006; by Lowtax

Carthag posted:

i dont either, i just was taught standard back in 03/04 and i remember there being a moscow variant too. its pretty shameful, i just wanted to fit in

sml has probably not changed since you were taught it. the main advantages of sml are (1) it has a formal specification, useful in pl research for proofs etc, and (2) the mlton whole program optimizing compiler is rather good. otherwise, the standard ml language is quite close to ocaml with some minor syntax differences, but ocaml has a more active community

from what i'm reading it looks like moscow ml was an early sml implementation based on some caml light code, it is probably obsolete now. the main ml dialects are ocaml, sml, and haskell

# ? Mar 9, 2013 06:58

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

JewKiller 3000 posted:

sml has probably not changed since you were taught it. the main advantages of sml are (1) it has a formal specification, useful in pl research for proofs etc, and (2) the mlton whole program optimizing compiler is rather good. otherwise, the standard ml language is quite close to ocaml with some minor syntax differences, but ocaml has a more active community

from what i'm reading it looks like moscow ml was an early sml implementation based on some caml light code, it is probably obsolete now. the main ml dialects are ocaml, sml, and haskell

thanks, makes sense

i think i might actually freshen up on it, if for nothing else than to just not coagulate.

# ? Mar 9, 2013 07:31