The document summarizes the design and implementation of a new programming language called newt. Key points include:
- newt aims to provide tight feedback loops through static typing and fast failure on semantic errors. It has succinct syntax while avoiding surprising behavior.
- The language is implemented in C++ and includes features like primitive types, arrays, records, functions, and automated testing.
- Challenges included generalizing type specifiers and making functions truly first-class. Future work includes collections, polymorphism, and syntax sugar.
Presentación para la charla sobre el libro de Robert C. Martin, Clean Code.
Esta presentación la impartí en CyLicon Valley, aquí tenéis el video con el audio de la charla => https://www.youtube.com/watch?v=1Fss1jBfc3g
Presentation I held before my colleagues about the book Clean Code (http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882).
It contains the highlights of several chapters and hint/guidelines a developer should know.
From Programming to Modeling And Back AgainMarkus Voelter
Is programming = modeling? Are there differences, conceptual and tool-wise? Should there be differences? What if we programmed the way we model? Or vice versa? In this slidedeck I explore this question and introduce interesting developments in the space of projectional editing and modern parser technology. This leads to the concept of modular programming languages and a new way of looking at programming. I will demonstrate the idea with tools that are available today, for example TMF Xtext, JetBrains MPS and Intentional’s Domain Workbench.
Presentación para la charla sobre el libro de Robert C. Martin, Clean Code.
Esta presentación la impartí en CyLicon Valley, aquí tenéis el video con el audio de la charla => https://www.youtube.com/watch?v=1Fss1jBfc3g
Presentation I held before my colleagues about the book Clean Code (http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882).
It contains the highlights of several chapters and hint/guidelines a developer should know.
From Programming to Modeling And Back AgainMarkus Voelter
Is programming = modeling? Are there differences, conceptual and tool-wise? Should there be differences? What if we programmed the way we model? Or vice versa? In this slidedeck I explore this question and introduce interesting developments in the space of projectional editing and modern parser technology. This leads to the concept of modular programming languages and a new way of looking at programming. I will demonstrate the idea with tools that are available today, for example TMF Xtext, JetBrains MPS and Intentional’s Domain Workbench.
Every project has a development standard.
Sometimes the standard is “if it was hard to write, it should be hard to maintain.”
Developing, and following, a corporate Best Practices standard will lead to continuity, maintainability, robustness, and pride.
Overview of Groovy language features and lead to Functional Programming in Groovy. As this is a code along session backed by this presentation, code examples are not include here as I code them live.
Every project has a development standard.
Sometimes the standard is “if it was hard to write, it should be hard to maintain.”
Developing, and following, a corporate Best Practices standard will lead to continuity, maintainability, robustness, and pride.
Overview of Groovy language features and lead to Functional Programming in Groovy. As this is a code along session backed by this presentation, code examples are not include here as I code them live.
Simulink - Introduction with Practical ExampleKamran Gillani
Simulink® is a block diagram environment for multi-domain simulation and Model-Based Design. It supports simulation, automatic code generation, and continuous test and verification of embedded systems.
This presentation will introduce you to programming languages that support different programming paradigms and to give you the knowledge of basic concepts and techniques that will allow them to differentiate between various programming paradigms.
BDD Testing Using Godog - Bangalore Golang Meetup # 32OpenEBS
BDD uses natural language to describe the "desired behaviour" of the system, that can be understood by both the developer and the customer
Demo of an existing BDD application using Godog predominantly used with golang
Functional Patterns for C++ Multithreading (C++ Dev Meetup Iasi)Ovidiu Farauanu
Discussing Design Patterns and OOP popularity,
Multithreading and OOP,
Functional Design for Multithreaded programming
and how Multithreading does not mean always concurency but multicore paralelism.
This fast-paced presentation is for the medium-level and higher LotusScript programmer who wants bite-sized lessons from the field. It's presented in three categories, covering tips you should be using, tips you should know, and finally tips that you should be aware of.
This presentation was also used for the speedgeeking session. I had to give a 60 minute presentation in 4.5 minutes, 12 times. I managed to complete it once, and averaged getting throught 22 tips. The fun thing about speedgeeking is that it does force you to think how you can compress down a presentation, and make each word fight for survival..
Program, Language, & Programming Language
Object Oriented Programming vs Procedure Oriented Programming
About C
Why still Learn C?
Basic Terms
C Stuff
C Syntax
C Program
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdfPeter Spielvogel
Building better applications for business users with SAP Fiori.
• What is SAP Fiori and why it matters to you
• How a better user experience drives measurable business benefits
• How to get started with SAP Fiori today
• How SAP Fiori elements accelerates application development
• How SAP Build Code includes SAP Fiori tools and other generative artificial intelligence capabilities
• How SAP Fiori paves the way for using AI in SAP apps
Le nuove frontiere dell'AI nell'RPA con UiPath Autopilot™UiPathCommunity
In questo evento online gratuito, organizzato dalla Community Italiana di UiPath, potrai esplorare le nuove funzionalità di Autopilot, il tool che integra l'Intelligenza Artificiale nei processi di sviluppo e utilizzo delle Automazioni.
📕 Vedremo insieme alcuni esempi dell'utilizzo di Autopilot in diversi tool della Suite UiPath:
Autopilot per Studio Web
Autopilot per Studio
Autopilot per Apps
Clipboard AI
GenAI applicata alla Document Understanding
👨🏫👨💻 Speakers:
Stefano Negro, UiPath MVPx3, RPA Tech Lead @ BSP Consultant
Flavio Martinelli, UiPath MVP 2023, Technical Account Manager @UiPath
Andrei Tasca, RPA Solutions Team Lead @NTT Data
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Monitoring Java Application Security with JDK Tools and JFR Events
Tools for the Toolmakers
1. Tools for the Toolmakers
Designing a Programming Language
2. Please Ask Questions (hold the rotten fruit)
● Tried to make an accessible presentation
● Don't know what the audience doesn't know
3. 0. About Me (and My Perspective)
● Back-to-school senior
● 4 years in industry with a large-scale C#/WPF code base, developing
computational geometry, CAD, and CAM applications and solving
optimization problems.
● Rails and Android apps here and there
4. 1.Pain Points
Programming languages are a pain sometimes
"Industry-strength" languages: C++/Java/C#
"Scripting" languages: Python, Ruby, Bash
Functional programming languages: Haskell
All of the above are brilliant, useful, and viable languages; this presentation
does not intend to denigrate or belittle
5. Pain Points: Syntactic Verbosity
Java (5 LOC, 120 chars)
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World");
}
}
Python 3.5 (1 LOC, 22 chars)
print("Hello, World")
Note: sometimes verbosity aids readability
6. Pain Points: Executive Verbosity
Java
$ javac HelloWorldApp.java
$ java HelloWorldApp
Python 3.5
$ python3 hello_world.py
Build tools (e.g. make) mitigate this problem somewhat, but introduce their own
complexity
7. Pain Points: Runtime Type Failures
Python
>>> 1 in ["1", "2", "3"]
False
Issue is kind of obvious here, but obfuscated by function calls and modules in
production code
A Youtuber I talked with confirmed that one frequently ends up re-inventing a
type system with unit tests
The Python community is working on this (see type decorators:
https://www.python.org/dev/peps/pep-0484/)
8. Pain Points: More Runtime Type Failures
Ruby
def is_thing (arg)
arg == “thing”
end
#the next statement evaluates to false: our function didn't check the type of its argument
#As with Python, this issue is obfuscated by layers of indirection
is_thing [“thing”]
def do_thing(a)
return a.specific_member #runtime failure if the member doesn't exist
end
9. Pain Points: Immutable Boilerplate
Immutability and constness are recommended defaults, but performing transforms
on immutable record types can be very verbose:
class Point {
public:
Point(const int x, const int y);
const Point* WithX(const int x) const { return new Point(x, m_y); }
const Point* WithY(const int y) const { return new Point(m_x, y); }
private:
const int m_x;
const int m_y;
};
10. Pain Points: Separate Declaration and Definition
Point.h
class Point {
public:
Point(const int x, const int y);
const Point* WithX(const int x) const;
const Point* WithY(const int y) const;
private:
const int m_x;
const int m_y;
};
11. Pain Points: Separate Declaration and Definition
Point.cpp
#include "Point.h"
Point::Point(const int x, const int y) : m_x(x), m_y(y) { }
const Point* Point::WithX(const int x) const { return new Point(x, m_y); }
const Point* Point::WithY(const int y) const { return new Point(m_x, y); }
Multiple signatures that must be kept in sync
Tooling can help (Eclipse's Implement Method feature is a life-saver), we shouldn't rely on tooling
if we don't have to
Somewhat poetically, couldn't fit the contents of both files on a single slide
12. Pain Points: Functional Language Syntax
String indexing in Haskell:
ghci> "Steve Buscemi" !! 6
'B'
Snippet from my xmonad.hs (is that a TIE fighter?):
main = do
xmonad $ gnomeConfig {
layoutHook = smartBorders $ layoutHook gnomeConfig
, workspaces = myWorkspaces
, manageHook = myManageHook <+> manageHook defaultConfig
} `additionalKeys` myKeys `removeKeys` disabledKeys
13. 2. Principles and Observations
As creators of software, automation is
what we do.
Examples of things that aren't automated:
Having to remember the types of
function parameters or look them up
in the docs
Writing code that validates the types of
function arguments
Writing unit tests to do type validation
14. Principles and Observations, the Continuation
Tighter feedback loops allow us to deliver better solutions faster
"Feedback loop" encompasses everything necessary to create a solution and be confident that it
works as intended
Authoring code
Semantic analysis
Unit testing, user testing, integration testing, etc
Requires succinct syntax and succinct build interface
Must identify defects as early as possible
Languages like Python initially give very tight feedback loops, then the loops get long
15. Principles and Observations
Conventions are important, but it's important they’re not astonishing
Astonishing behavior is inhumane, inducing stress and frustration
"Non-astonishing" usually means "familiar"
Follow established conventions where possible
Writing boilerplate code is frustrating and error-prone
Tools that generate code snippets are treating the symptoms, not the cause
16. Let's End the Pain
We can do better!
Or can we?
Ideas that sound good in principle can fall over when implemented
Ideas that are simple to describe in English can be hard to describe in code
17. Validation
Can we create a language that:
1. Consistently provides tight feedback loops
a. "Fails fast" and fails loudly
2. Has succinct syntax and grammar
3. Is readable and unastonishing
a. Doesn't violate existing conventions except where necessary
18. Failing Fast: Basic Definitions
Type
A shorthand for the properties of something in memory (e.g. an object)
and the manner in which we may interact with it.
Dynamically Typed Language
Variables are not associated with a type, and may be assigned a value of
any type. Values are generally typed.
Statically Typed Language
Variables are associated with a type, and may only be assigned values of
its type, or the type's subtypes. Typecasting is a hole in a statically typed language
(widening conversions are also questionable)
19. Failing Fast: Syntax, Grammar, Semantics
Symbol
A sequence of characters
Syntax
Legal sequences of symbols, usually described by a formal grammar
Semantics
The meaning of the syntax
Frequently analyzed without mathematical formality; type validation is part
of semantic analysis
20. Failing Fast: Semantic Analysis
Source Code ->
Lexer ->
Parser ->
Abstract Syntax Tree ->
Code Emission (or Interpretation) ->
Testing (hopefully) ->
Production
"Failing fast": push detection of defects as far up this stack as possible
Dynamically typed languages can't do semantic analysis until Testing stage
21. Readability
Sometimes conflicts with succinctness (see Game of Life example)
Sometimes in tension with verbosity (see Java's "Hello, World!")
Existing conventions shouldn't be violated without good reason
Example: parentheses are deeply associated with function invocation
22. The Language: newt
Derived from gpl, the domain-specific language (DSL) developed in Dr. Tyson
Henry's Compilers course
No geometry types or animation blocks
By extension, no tests for geometry types; all other tests are left intact, and are passing
No statement terminators (that is, no semi-colons)
More detailed error reporting, including column numbers
Generalized build system
Explicit errors
Representative--not exhaustive--set of features implemented for purposes of
23. Implemented Functionality
Primitive Types (bool, int, double, string)
Arrays (dynamically sized, multi-dimensional)
Record Types ("structs")
can be marked read-only
Basic Flow Control and Logic Operators
Functions
Recursive functions not implemented due to time constraints, but no implementation roadblocks
are known
24. Design Philosophy
Favor immutability and constness wherever possible
Diverged from this by allowing identifiers to be mutable by default; would like to change this
Syntax should require as little text entry as possible, without affecting readability
No significant whitespace, however, because it makes code refactoring harder to automate
Function declaration syntax sacrifices succinctness to aid readability
Errors are serious business
Nothing is executed until semantic analysis is complete
Nothing is executed if semantic analysis yields any errors
25. Notable Implementation Details
Object-oriented, written in C++
Mostly C++98, with a few C++11 constructs like auto
Favor immutability and constness, all the way down
Reentrant parser
Information about statements and expressions stored in the corresponding AST for error reporting
No implicit state (e.g. global variables) in the runtime
Vital for keeping execution state organized, particularly during function calls
Execution state captured in ExecutionContext objects that are passed around as needed
26. More Notable Implementation Details
Build interface is simple (requires Flex and Bison):
$ make all
Automated testing framework is simple:
$ make test
Very thin parser file compared to gpl
913 LOC, reduced from 1865
Semantic analysis is done in ordinary C++ code
Decision motivated primarily by tooling: Bison files aren't well-supported by my IDE of choice
Also a good separation of concerns: semantic analysis and parsing aren't the same thing and
don't mix well
27. Variables
Strongly typed
Distinct declaration and assignment operators:
a :int= 42 #declaration
a = 13 #assignment
Syntax motivated by "fail early" philosophy, variable shadowing, and first-class
functions (more on this later)
Type can be inferred:
name := "John Doe" #"name" will be of type 'string'
age := 42.5 #"age" will be of type 'double'
28. Flow Control
a := 15
if (a > 12) {
print("The world is flat.")
} else {
print("The rules no longer apply.")
}
Built to be as un-astonishing as possible to a C/C++/Java programmer
29. Arrays
arr:int[] #array of ints
Brackets go with base type (departure from C/C++)
Dynamically size
Static sizes seem possible because declaration operator is distinct from
assignment operator (this syntax is a recent change)
Inserting beyond the end of the array autofills any non-existent indices with
default values (this feels kind of weird)
Multi-dimensional
Array literal syntax not implemented, but it's quite feasible to do so
30. Record Types ("structs")
readonly struct Point {
x:int
y:int
}
p1 :Point= @Point with { x = 20, y = 30 }
p2 := p1 with { y = 56 + fun_call() }
p3 := p2 #create an alias for p2
Declaration maps identifiers to types; an instance maps identifiers to values
Not stored contiguously in memory
"with" syntax generates instances, either from a default value or another
instance (reminder: all types have default values)
31. Functions
First-class and higher-order functions ("functions as data")
Functions are assignable to variables
Functions can take functions as arguments
True first-class functions that close over their contexts
Not just function pointers
No statement terminators in combination with the chosen function type specifier
syntax gives rise to some complexity: fun := (a:int, b:double) -> int {} instead
of int fun(int a, double b) {}.
6 additional characters
32. Why First-class and Higher-order Functions?
They're shiny
Necessary for functional programming
Useful for
callbacks
generic sorting
map/reduce operations
33. Function Examples
#My First Function
add := (a:int, b:int) -> int {
return a + b
}
result := add(2, 3)
#Higher order function example (callback)
do_op := (value:int, callback: (int) -> string) -> int {
#do some processing here, possibly in the background
callback(value)
}
#some anonymous function action thrown in for free
result := do_op(3, (a:int) -> string { print("Good job " + a + "!") })
34. Automated Testing
Extensive automated test suite (~330 individual tests as of this writing)
Derived from gpl's test suite
For every bug, a test
Useful for testing semantics that cannot be expressed in the C++ type
system
Proved vital when developing new features in a way that didn't break existing
code
36. It's Better
I believe newt offers strong evidence that statically typed languages with
lightweight, fail-fast syntax and grammar are viable
Loss of succinctness in favor of tighter feedback loops as projects scale
Room for improvement here
Function declaration syntax
Function overloading and polymorphism
Distinct declaration and assignment syntax will probably stub toes (it still stubs
mine)
Dogfooding required
37. Caveats
Project has been active for 6 months
Compared to years for Ruby and Python and decades for Perl, Bash, and C++.
Comparing the number of person-hours is even more amusing
Rome wasn't built in a day, and programming languages aren't built in a half a
year
38. Lessons
Large projects are collaborative efforts. You can't do it alone (but nobody will do
it for you either)
Build a good foundation. Get the tooling right. Get the environment right.
Automate all the things, and don’t repeat yourself (without damn good reason)
The following tools are non-optional:
Version control. You cannot maintain the entire project history in your head, and it’s a waste
of cognitive resources to try
Automated regression testing. One cannot maintain the entire state of a non-trivial project in
one's head, so you cannot completely validate a change or enhancement without
automated testing.
39. Lessons
The complexity in any nontrivial system is a result of the interaction of its parts
Example: C-style declaration syntax doesn’t mix with first-class functions that share symbols with
function invocation
Separation of concerns is a real thing
Doing semantic analysis in the parser can make it difficult to reason about the code
The implementation of a well-designed language is so regular it’s almost boring.
Patterns are everywhere, but exploiting those patterns can be time-
consuming
40. Lessons
Statement terminators (e.g. semicolons) make parsing easier
But I'm glad newt doesn't have them, because they're not very succinct
Using enums for type specifiers isn't very extensible
dynamic_cast is usually code smell, but sometimes necessary
Get the parser working correctly before writing the implementation
Linked lists are an interesting way of expressing immutable ASTs, but they
aren't always simple
For example, newt generates a linked list of parameters, but it has to be reversed before
processing
44. Notable Challenges
Minimizing the build system
Basic Assignment (widening conversions are painful)
Arrays
Generalizing type specifiers
Making functions first-class
45. Wishlist
Collections (sets, array literals, etc)
Polymorphic functions
Option types
Syntactic sugar for structs
Syntax highlighter and code formatter
More versatile test suite