[erlang-questions] Rhetorical structure of code: Anyone interested in collaborating?

Oliver Korpilla <>
Thu May 5 17:19:38 CEST 2016


It's kinda sad that someone would come up with such a lame conclusion and such woefully incomplete analysis, especially at MIT.

Yes, I agree, I do poke libraries a lot to see what they can do. But that is only part 1 of my job.

In part 2 to n I take all I know to create my part on top of it, or even to replace parts that I don't like.

I mean, I had several pitfalls during learning about Erlang, OTP, and Elixir. That certainly was poking. But without the lessons from SICP and other materials I absorbed throughout the years, where would I go from there? Nowhere. Or somewhere with lots of badly hacked code that will others wish I hadn't.

It seems to me this is more a tale of burnout... and maybe even spending too much time in a certain corner of academia. If you get your hands dirty for a prolonged time on a project I don't think you will poke your libraries forever, but rather write whole new ones, some of them just to compensate for the shortcomings of existing ones. And you will create. And reason. And design. And analyse. And yearn for better, more succinct, more concise ways to build software and get ideas from your head into those damn stupid computer things.

I don't think poking is enough in any domain. I love Python, but I am glad I actually worked through SICP on my own.

Oliver
 

Gesendet: Donnerstag, 05. Mai 2016 um 17:04 Uhr
Von: "Garrett Smith" <>
An: "Lloyd R. Prentice" <>
Cc: erlang-questions <>
Betreff: Re: [erlang-questions] Rhetorical structure of code: Anyone interested in collaborating?
I was initially excited to read what great breakthroughs in
teaching/learning methods this piece would reveal.

But it's just terribly sad. If programming was poking at things I
didn't understand - in Python moreover - boy I'd be in another
profession. I feel bad for those students.

On Thu, May 5, 2016 at 9:51 AM, Lloyd R. Prentice <> wrote:
> Pertinent to the discussion:
>
> PROGRAMMING BY POKING: WHY MIT STOPPED TEACHING SICP
>
> http://www.posteriorscience.net/?p=206
>
> Best wishes,
>
> LRP
>
> Sent from my iPad
>
> On May 5, 2016, at 6:07 AM, Vlad Dumitrescu <> wrote:
>
>
>
> On Thu, May 5, 2016 at 1:19 AM, Richard A. O'Keefe <>
> wrote:
>>
>>
>> On 4/05/16 6:49 PM, Vlad Dumitrescu wrote:
>>>
>>>
>>> I don't disagree with you, it's just that for projects larger than toys,
>>> I don't know how to browse the history for something that i don't know what
>>> it looks like and that might or might not be there. Taking erlide as an
>>> example, there are 6000 files in 7000 commits in the main branch, going back
>>> 13-14 years and if i would have saved all experiments I'd probably have a
>>> tree of at least 5 times that much. I am certain that I wouldn't be able to
>>> find anything faster than I would write it again from scratch.
>>
>>
>> With 6000 files of totally unfamiliar code, there's no way I could find
>> anything without a map and ground approach radar. (find . -type -f -print
>> |
>> wc actually counts 2774 files; it did report 6186 before I got rid of all
>> the '._*' junk files you get on a Mac.) OK, so 1344 Java files, 38 Erlang
>> files, 2 Ruby files, 1 XSLT file, and 50-odd Xtend files (which I can't
>> read
>> yet), even hamcrest (oh don't get me started on hamcrest)...
>
>
> Yeah, I think I forgot to filter out the binary files. Anyway, the point was
> that at that size, having a multitude of alternative histories, many of
> which might not be relevant at all any more, it gets exponentially harder to
> be able to find anything in there.
>
>>
>> With the ._* junk removed, I measure 33.6 MB. This one Eclipse plugin
>> is bigger than the whole Quintus Prolog system, including manuals.
>>
>> Not only that, it's more than half the size of Pharo, which is a complete
>> Smalltalk system including the refactoring browser. There seems to be
>> something about Java that forces systems to grow exceeding large.
>
>
> Yes, and most of the important stuff (the Erlang implementation of the
> kernel functionality) is located in another repository. I also had to
> include some third party libraries as sources, in order to not depend on
> external stuff whose availability was unreliable.
>
>>>
>>> We would need an index of the important experiments, with a reason why
>>> they didn't were chosen for implementation and maybe a brief description of
>>> the design, and a reference to the commits. This requires a lot of
>>> discipline to maintain (especially when a team is working on the project,
>>> with each person doing its own experiments).
>>
>>
>> Such a thing would, however, be extraordinarily useful for someone in my
>> position, with NO idea of where to look for ANYTHING, and a dead link to
>> documentation. The README.md file contains this line:
>>
>> Documentation may be found at
>> [the project site](http://erlide.org/erlide.html[http://erlide.org/erlide.html]).
>>
>> That site isn't supposed to expire until next year, but right now it's not
>> accessible. So yeah, I'd find lots of history very helpful. And lots of
>>
>> advice for the traveller.
>
>
> Thanks for pointing that out, I fixed the link. I will try to keep such a
> high-level history from now on, I'm sure there will be a lot to learn for
> myself too.
>
> best regards,
> Vlad
>
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]
>
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]
>
_______________________________________________
erlang-questions mailing list

http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]


More information about the erlang-questions mailing list