|
Cybernetic Vermin posted:Any more details (names, urls?) on this? K remains one of my great loves, but suffers from its proprietary nature (as well as from being entirely incomprehensible until you have some practice, which I understand has been carried over). How about a browser-based implementation of K with a set of graphical programming extensions that can be used to make pointless but pretty tech demo things?
|
# ¿ Nov 24, 2015 17:41 |
|
|
# ¿ May 2, 2024 02:35 |
|
You guys were basically launching signal flares with my name on them. It's very interesting to see that the Forth and APL communities seem to have so much overlap. "write only" languages evidently have to stick together. One of these years I'm seriously going to have to make the trip to Forth Day- thanks for the trip report, Gazpacho. edit: Listened to the CoSy talk. It was a bit meandering and rambly but I think it mostly made sense to me. CoSy aims to be a forth-like, low-level language and programming environment which provides direct access to hardware, with the high level expression and data manipulation of APL. APL implies managed memory, so CoSy, like K, uses reference counting. CoSy structures have a uniform header structure which tracks a type (including types for unityped vectors versus heterogenous lists), a size, a refcount and a slot which permits any data structure to be annotated with arbitrary metadata- similar to Lisp plists. Forth typically stores all static data and word definitions in a dictionary. Special words for manipulating this dictionary are part of a typical kernel, and for most purposes it is append-only. CoSy keeps its dictionary in one of its refcounted structures (named R), permitting all the APL-style words to operate on it. Recommended video, a Google Tech Talk about the current state of Dyalog APL: https://youtu.be/PlM9BXfu7UY For the most part the curses ASCII-art visuals are just the way code or comments happen to be formatted for the presentation, and don't have anything to do with the language. It looks like the pipe character (|) is being used to delimit line comments, if that helps. You can see some evidence of a "block oriented" approach to breaking up/storing code in fixed-size "pages", which is a historical artifact of how early forth systems and their built-in text editors worked. The IDE you can see in most of the presentation has a REPL output panel on top and a persistent text editor at the bottom, and the presenter is navigating his notes and occasionally evaluating fragments of them, displayed at the top. Emphasis is placed on CoSy's features for searching, timestamping, and interactively testing code- CoSy is essentially similar to Mathematica's "workbook" concept of blended interactive examples, output and notes, centered around a Forthy environment and permitting dropping into x86 assembly language when desired. Internet Janitor fucked around with this message at 21:20 on Nov 24, 2015 |
# ¿ Nov 24, 2015 17:55 |
|
would there be actual interest in an APL/J/K thread in CoC, or would it just be pages and pages of "this is unreadable", "what's with the funny symbols", etc
|
# ¿ Nov 30, 2015 02:22 |
|
Cybernetic Vermin posted:oK from a few pages back depress me by seemingly not allowing indexing an array with a dictionary, though it may be some K5 change which i am unaware of It's a K5 limitation, I'm afraid. Many things have been aggressively simplified compared to K4. There's still a reasonably simple K5 formulation. No repeat values: code:
code:
|
# ¿ Nov 30, 2015 20:44 |
|
alright, i did it: http://forums.somethingawful.com/showthread.php?threadid=3754012 can't really go much worse than my forth thread did.
|
# ¿ Dec 1, 2015 21:19 |
|
I'll bitch about Python just about any chance I can get, but ever since I learned Java had labeled breaks I have searched for an appropriate opportunity to employ them. I've tried for years to come up with a good excuse to use this feature and baffle onlookers, but every time I've tried it turned out to be cleaner to structure the code in some other way- collapse loops, break out a function, etc. In all seriousness, what's your use case?
|
# ¿ Apr 24, 2016 08:51 |
|
pointsofdata posted:in practice it's more like 1.3gb for some reason Is the reason that modern Office files (OOXML) are literally zip files with internal package structure, and 1.3gb is about how large a compressed file is which decompresses to something that exhausts a 32-bit address space?
|
# ¿ Apr 25, 2016 20:22 |
|
Communist Pie posted:from functools import reduce code:
|
# ¿ Oct 29, 2016 03:12 |
|
If anyone's genuinely curious about K, I suppose it might be appropriate to plug the APL/J/K thread again. As of a few months ago I'm actually a professional K programmer now. At the company I work for it's used for everything from deployment automation and expression parsing to web scripting and distributed databases. Even after spending some time wading through and cleaning up real-world K codebases, warts and all, it remains one of my favorite languages. Though it may seem implausible, it does become quite readable with practice. When you're used to K, more conventional languages often feel needlessly verbose and clumsy.
|
# ¿ Nov 1, 2016 03:06 |
|
MononcQc posted:Do I need to be a fancy maths person to use a language like K ? Nope. I mean look at me; I'm just a janitor. K is a simple, very regular functional programming language with well-thought-out behaviors. For example, applying a function and indexing a list uses the same syntax: code:
code:
code:
code:
K isn't going to be for everyone, and it doesn't shine for every problem domain, but it is eminently learnable and teaches a nice way of thinking about solving problems. Programming in K makes me very happy, and I hope more people give it an honest try.
|
# ¿ Nov 2, 2016 04:11 |
|
The Forth and APL communities can be a bit depressing. Both languages cling to life in weird niches isolated from mainstream software engineering and computer science. There are some brilliant people with neat ideas in each camp, but there's a huge chasm between those worlds and the ones everyone else programs in. They have a tendency to come across as impossibly quaint and sheltered. The more time I spend studying them the more certain I am that both have written themselves into extinction patterns. The languages are good, but the communities may be unfixable.
|
# ¿ Nov 20, 2016 16:12 |
|
pokeyman posted:oh so it's like php "What if the world were made of Strings?" -> Tcl. "What if the world were made of cons pairs?" -> Lisp. "What if the world were made of rectangular arrays?" -> APL/J. "What if the world were made of chewing gum and baling wire?" -> PHP. From an educational standpoint, Forth is a good language because it is extremely simple and flexible. A cute metacircular Lisp evaluator fits on about a page, but leaves out many essential details of a functioning interpreter- parsing, garbage collection, the environment structure, etc. You can write a Forth that runs on metal in a few pages of assembly language and actually understand how every piece works in detail. I think it's a valuable intellectual exercise if nothing else. For practical application development anywhere outside embedded systems it's admittedly hard to make a case for Forth. APL and its descendants are good languages because they succinctly capture a good way of thinking about problem solving; notation as a tool of thought. Idiomatic APL is naturally data-parallel and, by virtue of not needing many (if any) control structures, is very easy to test and develop interactively. Modern scientific computing libraries like Pandas are essentially converging towards ideas that first arose in APL, so even if you don't like APL's syntax, I think one could argue that the semantic flavor of these languages is winning out. I've found K to be a lovely language for livecoding and prototyping graphics programs (albeit using my own tools), and I think it is well-suited to a variety of situations where a programmer wants to perform ad-hoc data analysis.
|
# ¿ Nov 21, 2016 04:32 |
|
VikingofRock posted:"arity" is such a weird word. I occasionally feel the same way about "tuple" as well The APL community uses the much cooler word "valence". Functions which accept a variable number of arguments are, naturally, "ambivalent".
|
# ¿ Jan 31, 2017 15:23 |
|
most of the time a longer name for a local variable is just longer. {[number;number] number*number} is not clearer than {x*x}. how many times have you written a loop with an induction variable and named it index or counter or i or whatever? it's a stereotypical pattern, not documentation. K makes x and y always have the same semantic meaning when you encounter them. stereotypical patterns like ,// and {x@<x} always look exactly the same, and there's a very good chance that two trained K programmers will come up with character for character identical programs to solve a given problem. this kind of uniformity is actually an extremely good thing for readability and maintenance, it just disagrees with conventional wisdom.
|
# ¿ Feb 23, 2017 01:57 |
|
Rice's theorem tells us that it is impossible to statically determine nontrivial semantic properties of programs that run on a Turing machine. Type systems produce simplified abstract models of programs which are (hopefully) tractable to analyze. In my experience, the utility of static typing relates to the scale and complexity of a program. Short, simple programs fit inside my skull at once, and while static types may still be a useful mental discipline, I can do without them just fine. I can see why people who mostly work on small, independent programs would consider static type declarations needless overhead. As programs become larger and are maintained by many people they no longer fit in my head at once. Static checks become extremely valuable indicators that global properties of a codebase are retained as I make changes. Tests can provide the same guarantees (and are the only way of verifying behaviors a given type system can't capture), but a compiler is far better at enforcing constraints consistently than programmers. I think relatively simple static type systems (say, something like Pascal) capture much of the low-hanging fruit. As type systems become more complex, there's a diminishing return. Some programmers seem to become so caught up in building and exploring type abstractions that they lose sight of programming.
|
# ¿ Feb 26, 2017 15:52 |
|
c is named after the speed of light because many people think it is the fastest a programming language can be.
|
# ¿ Mar 1, 2017 00:59 |
|
Zemyla posted:I half-imagined that the "code in two columns" thing was for concurrency. http://www.linusakesson.net/scene/bitbanger/index.php
|
# ¿ May 24, 2017 23:41 |
|
Cybernetic Vermin posted:they should certainly be, in k they have the good taste to make it rather explicitly so (though, granted, that also entails making dictionaries ordered, but that has distinct upsides as well) rjmccall posted:i will point out that there is a rough equivalent of concatenation for dictionaries, dictionary union, where the result has all the entries of both dictionaries. of course you have to handle semantic conflicts, either by arbitrarily preferring one of the inputs or by somehow merging them the bleeding-edge experimental flavors of k do in fact define dictionary overloads for most primitive operators. it's really nice: code:
Internet Janitor fucked around with this message at 01:36 on Jul 18, 2017 |
# ¿ Jul 18, 2017 01:32 |
|
MALE SHOEGAZE posted:are there any terrible programming languages with roman numeral literals? i'm really sad this was rejected. just imagine the hysterical stack overflow questions about how naming a variable "X" or a class "DLC" produced baffling misbehavior. also this disclaimer would not be out of place in a hacker news comment: quote:Programs that use variable names that are all upper case and contain only the characters M, D, C, L, X, V and I will be affected by the new literals. These programs will now have syntax errors when those variables are assigned, and either syntax errors or subtle bugs when those variables are referenced in expressions. Since such variable names violate PEP 8 [3], the code is already broken, it just wasn't generating exceptions. This proposal corrects that oversight in the language.
|
# ¿ Aug 28, 2017 02:44 |
|
Asymmetrikon posted:can someone make a language that refuses to compile if the source code is not in the proper style? just like, bake indentation into the parser and make sure each line is max 100 chars or whatever long quote:INTERCAL has many other features designed to make it even more aesthetically unpleasing to the programmer: it uses statements such as "READ OUT", "IGNORE", "FORGET", and modifiers such as "PLEASE". This last keyword provides two reasons for the program's rejection by the compiler: if "PLEASE" does not appear often enough, the program is considered insufficiently polite, and the error message says this; if too often, the program could be rejected as excessively polite. Although this feature existed in the original INTERCAL compiler, it was undocumented.
|
# ¿ Aug 28, 2017 03:37 |
|
tef posted:what if we wrote a language for people who werent showboating assholes though this was supposedly an explicit design goal for go, and what we got instead was a language designed by showboating assholes for people they think are stupid and incapable of learning
|
# ¿ Oct 15, 2017 13:55 |
|
in practice i have a pretty sour opinion of go because all of the go codebases i have seen, including those written by experts and contributors to the language itself, are composed of reams upon reams of repetitive, copy-pasted logic. whether it is the lack of generics driving people to manually template-expand custom data structures, the lack of exceptions driving people to manually template-expand error propagation, or the general fear and loathing of anything except endless fields of for loops cultivated by the community's vocal anti-intellectual stance, golang appears to cultivate technical debt. it's like a built-in linguistic broken-window scenario: tools to abstract and reuse code reasonably do not exist by design so huh I guess I'll just mound on more garbage. how simple. at the micro level, go code is indeed straightforward and permits local reasoning. i argue that the sprawl of go codebases more than compensates for this benefit.
|
# ¿ Oct 15, 2017 17:11 |
|
rt4 posted:frankly learning how to use lisp languages has eliminated my patience for learning any other syntax same, except k
|
# ¿ Oct 26, 2017 05:39 |
|
my hot take: people who think they are familiar with the pitfalls of c are even more dangerous than cautious beginners or zed shaw esp. anyone who talks about how c is a "portable assembler" because it has an obvious mapping to machine instructions
|
# ¿ Nov 24, 2017 15:33 |
|
cinci zoo sniper posted:that has me wondering if it is an attempted bone for static typing crowd, or do they have further plans? i assumed it was based on the same kind of petulant fake compromise wherein guido removed reduce from the functions in the default namespace on the basis that the only things he could possibly imagine using it for were calculating the sum or product of an array "well gosh everybody makes a huge deal about how they like static types; i don't even get why you'd want them. fine here have annotations. what are the semantics? dunno, whatever the reference interpreter does. anyway now that's settled once and for all."
|
# ¿ Nov 26, 2017 21:08 |
|
the real question here is how does wasm make browsers a more compelling and effective platform for the most important class of users by which i obviously mean advertisers
|
# ¿ Dec 27, 2017 04:49 |
|
how does wasm help companies ram ads straight up everyone's orifices every time they visit a web page ever can the new dom apis be designed in such a way that they "accidentally" make content blockers impractical or impossible to implement perhaps
|
# ¿ Dec 27, 2017 04:54 |
|
Xarn posted:
|
# ¿ Dec 31, 2017 19:22 |
|
forth never achieved enough dominance or collaboration to get much of a PR presence; at its height it was mostly EEs quietly applying it to their problems and never sharing their code with anyone. that it is so easy to build a forth means everyone makes their own incompatible needs-suiting implementation and the community gains no force multipliers. guilty here. in contrast lisp has many "enthusiasts" who write little code but treasure vague aspirations and legend. even today one need only mention lisp in passing for lispers to crawl out of the woodwork to explain how lisp is "good for ai", lisp has had every language feature forever, a metacircular evaluator is the most beautiful program in the world, &c, &c.
|
# ¿ Jan 2, 2018 14:55 |
|
demographically, people with cs degrees and/or significant non-apl experience tend to have very strong negative reactions to apl-family languages apl has largely clung to life via people who are technical, but not traditionally educated as programmers, and therefore willing/able to get past how alien apl is compared to most other things. downside to this is the apl community on average has a weak grasp of many genuinely useful mainstream practices like using revision control systems or contributing to open source. the situation does seem to be getting a bit better lately. i love catching lisp weenies talking about how sexprs (aka "no syntax" or so it is claimed) are perfectly readable if only people would put in some effort to get used to them, and then turning around and shrieking in fear and anger at apl's literally impossible, unusable, unlearnable, inhumane, but most importantly, unfamiliar, syntax.
|
# ¿ Mar 4, 2018 20:01 |
|
visual programming languages are an idea so tantalyzingly obvious. so seductive. by unfurling our linear programs into 2d diagrams, they will become intuitive. why, even a child could follow a flow-chart which converts temperature in fahrenheit to celsius and understand how it works! at a glance! python by comparison is a hopeless miasma; a sea of bizarre punctuation characters and juxtaposed sentence fragments. structure is far less obvious and natural than in the graphical presentation. the age of text-based programming is dead! we will never be free of this spectre. simple things are so simple in visual programming languages that the mounting inconvenience of building large, complex programs in this fashion will only ever be discovered when things are far too late. the incidental problems of planar layout, the need to reinvent all the tools available for text- fuzzy searching, revision control, diffing, etc- the aching slowness of dragging together programs box by box and threading them together. these are all a slow chilling after the initial excitement. perhaps if we we just stacked the boxes like this, or used color-coded handles, or made it more like a spreadsheet- yes, it will all be different this time. visual programming has been the way of the future for 50 years, in countless guises, and I have no doubt it will keep resurfacing and failing for the next century.
|
# ¿ Mar 9, 2018 15:14 |
|
rjmccall posted:these people also come out of the woodwork on every programming language project, apparently just to lord over us how pointless our life's work is going to be and then the other people chime in about how we should just edit ASTs using a Sufficiently Advanced Editor and then every user can dynamically reskin those to resemble their favorite language and how this would solve essentially all the problems in programming language design and code collaboration i'd actually love to watch someone try using such a system on a large project and plot their blood pressure with respect to time
|
# ¿ Mar 9, 2018 23:35 |
|
the idea of prolog is to describe your input and output and the language furnishes a program. in trivial cases this works. in meaningful cases it's intractable. in practice, the idea of prolog was a complete failure. prolog the actual language is kind of a neat way of thinking about some things, though. writing programs that are not restricted to a narrow domain is intrinsically, inescapably difficult. we still can't really teach humans how to compose complex programs, so it shouldn't be surprising that we have met with limited success in replacing programmers with programs. i think the best thing to aim for is tools and techniques to help people manage the complexity of software, rather than hoping to hide it or make it disappear via some sleight of hand.
|
# ¿ Mar 10, 2018 06:15 |
|
let's just get rid of the parens entirely, and make it more clear when we're dereferencing a variable: y @ 1 + 12 * x !
|
# ¿ Apr 7, 2018 17:39 |
|
eschaton posted:just provide downloadable binaries for a couple common platforms that people can try speaking from personal experience, if you want people to tinker with a language you will get many more people to try it if they can follow a hyperlink and then immediately start using it. Athas, if you build a browser-based sandbox for Futhark it doesn't take much more effort to include pastebin-like functionality so you can share a link to code and someone else can run and then modify it. it would be cool to see your language in a shadertoy-like environment. could also be a really nice way to obtain a corpus of smallish programs written by not-you for regression testing purposes.
|
# ¿ Apr 24, 2018 13:41 |
|
https://storage.googleapis.com/golang-assets/go-brand-book-v1.0.pdf this is the most branding package i think i've ever seen
|
# ¿ Apr 27, 2018 05:30 |
|
yeah, there's no excuse not to ship every electronic product with a massively overspecced SoC running a heaped-together pile of off-the-shelf software mostly written by volunteers and never audited by anyone ever on an unrelated note, my light bulbs are turning themselves on and off, my shower head seems to be transmitting nude photos of me to a cryptic chinese website, and my front door refuses to unlock unless i feed it bitcoins
|
# ¿ Jul 25, 2018 23:19 |
|
Stringent posted:i think the important distinction here would be is there any case where the finally() block would not run, but the rest of the program would. the answer to that should be no, but who the hell knows anything i assume that the point of the exercise was to tease out something like code:
code:
|
# ¿ Aug 30, 2018 04:14 |
|
Zlodo posted:the problem with garbage collectors is that they are usually black boxes because they are designed around a "don't worry about memory, we'll take care of it" philosophy how do you feel about your processor's cache
|
# ¿ Oct 21, 2018 15:55 |
|
|
# ¿ May 2, 2024 02:35 |
|
python's braindead approach to whitespace makes copying and pasting code from the internet very likely to completely mutilate it and require careful re-reading and re-indenting. as a way to deter novices from blindly kludging together code they haven't read, i almost like it almost
|
# ¿ Nov 18, 2018 17:15 |